PLEASE TEST. Commit in prep for Tech Preview 2 release

I think that we're going to need an image manager for sure... loosing that would be bad for the next preview ... a step back from HTMLarea.

Raymond, can you get HTMLareas Image Manager working with Tiny/FCK?

Raymond, can you get HTMLareas Image Manager working with Tiny/FCK?

Sure can but let me finish up with the modules stuff then I'll take some time and merge my changes with the Trunk then merge with Jason's and Travis' branch. What exactly has changed in Travis branch?

__
Raymond Irving

Among the changes in my branch:

Changed all $etomite and $modx references into $tattoo
Standardized declared variables
Purged remaining references to Etomite call home functions.
Initial code cleanup and commenting.
Relocated config.inc.php to /assets to support multiple sites from one manager codebase. Adjusted installer.
Removed unnecessary files.

There are some other small fixes and such as well, but those are the biggies. My non-commited code builds on these changes and pretty much revamps every backend file.

Raymond, can you get HTMLareas Image Manager working with Tiny/FCK?

Sure can but let me finish up with the modules stuff then I'll take some time and merge my changes with the Trunk then merge with Jason's and Travis' branch. What exactly has changed in Travis branch?

__
Raymond Irving

Raymond, my branch has already been merged with the trunk. I'm going to make some changes to the configurations and configurability of the editors, and continue to try and get the image/file managers that come with them to work within our installation.

After that, I'm going to look abstracting the editors in the form of a definable interface for providing implementations, including allowing plugins like mmjaeger's iManager to be used in any of the editors, as an alternative file/image manager.

Travis' branch contains general cleanup, commenting, and changes from modx to tattoo where appropriate. This merge should be reserved for the official Tattoo release.

IMO, if we want to continue to support the HTMLArea image manager, I think we should do so in conjunction with the plan to abstract the WYSIWYG editors, and only if adoption of Xihna as an alternative WYSIWYG editor is successful, or it can be plugged in to the available editors in much the same way as iManager.

BTW, the image editor from HTMLarea has been made standalone. Should be trivial to add support for the other two editors to use this now.

https://sourceforge.net/project/showfiles.php?group_id=92873

Installs fine, but I get this (twice) on the manager login page, and this is all I get on logging in.

Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /Library/WebServer/Documents/trunk/manager/includes/document.parser.class.inc.php on line 502

Bypassed above issue by just removing the & from the arguments, and logged in OK, opened the System Configuration, and several of the items are displayed badly (narrow column under the label, or way off on the right side, clear off the page), and the "cleanup" page reloading problem is still alive and well. This is with the new Safari.

Among the changes in my branch:

Changed all $etomite and $modx references into $tattoo

hmmm, I thought we would keep $modx at the parser level since it could be simply transultated as modular and extensible parser. So we called it the modx parser?

Relocated config.inc.php to /assets to support multiple sites from one manager codebase.

How would this work? Couldn't these sub sites use manager/includes/config.inc.php the same way?

NOTE:Moving the config.inc.php file into the assets folder would break the $base_url and $base_path php logic.

Among the changes in my branch:

Changed all $etomite and $modx references into $tattoo

hmmm, I thought we would keep $modx at the parser level since it could be simply transultated as modular and extensible parser. So we called it the modx parser?

Relocated config.inc.php to /assets to support multiple sites from one manager codebase.

How would this work? Couldn't these sub sites use manager/includes/config.inc.php the same way?

NOTE:Moving the config.inc.php file into the assets folder would break the $base_url and $base_path php logic.

IMO, to really clean up everything, both the manager and the site itself should have their own set of $base_path, $base_url, and $site_url variables. And these should be accessible as configuration settings that can be set to something specific if need be (e.g. supporting IIS or other non-Apache servers).

I've also had to make some changes in some of this so it works when loaded from paths that have more than one "manager" instance in the string (was returning bad results when loaded in FCKeditor's /filemanager directory). A hack at best.

hmmm, I thought we would keep $modx at the parser level since it could be simply transultated as modular and extensible parser. So we called it the modx parser?

No. The product is named "Tattoo", not "modx". People coming to the product once 1.0 is released should not have to deal w/ its history but what it is. Doesn't make any sense to call it one thing and then use something else internally. If we were going to call it something other than its name, it should have been left etomite.

NOTE:Moving the config.inc.php file into the assets folder would break the $base_url and $base_path php logic.

Already corrected as part of my changes. My branch installs and works 100%.