Hello Guys!
For you rasc:
Note: ManagerManager is not compatible with Manager plugins which use Mootools library, including ShowImageTVs. It is suggested that you disable the ShowImageTVs plugin, and use the mm_widget_showimagetvs widget instead, e.g. add this line to your rules:
found in the current docs of 0.3...
What about your mootools based version?
Its a kind of manager-interface "sub-system" i call it "UIx"(User-Interface xtender). You can do a lot of things with it. It cover all things what mm can do and many more. Its working well, but its also beta... since 2006... damnit, it grow up and need more hands than my own as well as content_history. I stack at a ajax interface to setup the actions by a smart form but.... i fall back to config-files for the actions.
for example
plugin-config :
set rules when the actions should run: use parent, document(id), role or a manager-action. The actions are written in the file you choose. In this case its "demo1.php" for the document-edit-page
demo1.php
$this->runAction('extra_tv_categories','1'); the TVs will be transform to a Tabpane.
And is this not enough, you can move "sections" as a tab to another tabpane
$this->runAction( 'section_move_to_tabpane', 'tv>>documentPane' );
the content or permisson section as well
$this->runAction( 'section_move_to_tabpane', 'content>>documentPane' );
Ist also possible to create widgets and bind them to a field you want.
$widget = array(
’img_path’ => ’assets/images/’,
’bindto’ => ’tvadresse_bild’,
’css_class’ => ’imagebrowser_mini’, // should be automaticly the widgetname
’toggle’ => ’1’ // open/close buttons
);
$this->runWidget(’imagebrowser_mini’,$widget);
and so on, you can do a lot of actions. look to the left side on the screenshot, all actions are stored in folders. Its possible to create new functions for the document overview-page. E.g. if your modx is a shopping system, so the doc-overview page of a product(template) have another look than the overview page for a product-container(category)(template).
why this stuff is not published? Good question... shame on me... i not sadisfy with it... i think the code looks ugly and unstructured and needs many brain which i not have... And there is a thing that could cause some problems. This is: first at all, i run a js-script that transform the sourcecode to the following stucture
<table class="fieldtable" cellpadding="0" cellspacing="0">
<tbody id="fieldcontainer_General">
<tr id="fieldrow_pagetitle" class="fieldrow">
<td class="fieldrow_col_description">
<span class="warning">Pagetitle</span>
</td>
<td class="fieldrow_col_input">
<input name="pagetitle" .... >
</td>
</tr>
.....
so ist very easy to move a field
$(’fieldrow_pagetitle’).incjectInside(’fieldcontainer_Settings’);
Just move the tr to a tbody you want. Or inject it before or after another tr.. All tr-elements now have an Id. Its easy to catch every field with js.
Set a description to pagetitle: a hidden html is created:
<p id="uix-description-pagetitle">description for pagetitle</p>
$(’uix-description-pagetitle’).injectInside( $(’fieldrow_pagetitle fieldrow_col_description’) );
So its very easy for a developer to place something at an abitary field.
But in the 963er Version the the underscore "_" is urlencoded, so the prepare.js is broken and the js functions that based on the structure above.
Here is a bridge to the next content-history: i will inject the history of every input-fild next by it. For that i need this prepare.js or better the hole uix to do this job.... And... i also wrote a translations class... for all plugins or snippet. I will use that to translate every damnit message i will output in "ch", "uix" or other snippets and plugins..... you see where my problems are? unorganized bullshit all around, many ideas and less time... i need the prepare.js for content_history and for uix but the right way is use it once for all(same according to the translation class). Its a organization problem and how many "specials" a modx user can bear...
My goal is or should be:
1. one package to translate whatever and whereever a message will be translated (multilanguage_translation)
2. one package to create a tab/section with abitary content whereever inside the manager( uix )
3. one package to handle the history of a document (content_history .. use uix to incject the section and ml_translation to put out messages with the right encoding and the proper language)
Should i wait to the working revo? I think a stucture like my wish is already nativly possible with it. Or should i do the stuff for the 96 branch.... This will look complex and isnt just a single plugin.
Guys... i feel.... I NEED HELP, NEW BRAIN AND FRESH IDEAS! And i will be full of thanks for all help which will comming.
Give me the time to write a documentation/quick instruction, after that i will provide my svn url. Don’t Panic, i am on my way. This will not take so much time as my last prognosis.
Enough tears
As for Deutsch and utf8 I was only referring to code comments which somehow, despite the best intentions, get scrambled by going through 8859 somewhere in the process across various machines.
I see the problem. I save all my files with utf-8 encoding. if you load this files with 8859 output the source change to bullshit. The fast help could be:
Edit the files
/inc/events/docformrender.inc.php
and
/inc/events/pluginformrender.inc.php
in both files change the lines
$e_output = ob_get_clean();
$e->output( $e_output );
to
$e_output = ob_get_clean();
$e_output = utf8_decode( $e_output );
$e->output( $e_output );
I hope this will help you. Your right, this is a bug. Don’t cry, i will fix this point.
Also the show/hide icon isn’t a toggle switch is there any chance that it could be setup that way instead of forcing us to click the text?
Generally, this sounds not good. All work or nothing work... i hope its just the click..
Edit /skin/default/content_history.tpl.phtml (or copy it to your own namespace and change the skin-switch see the posting above)
LIne 95, 96
<!-- section body -->
<div id="ch-body" class="sectionBody hidden" style="display:none;">
Change display:none to display:block or remove the hole "style" attribute.
And? do you get the full view?
Adios, Stefan
☆ A M B ☆
.
☆ A M B ☆
