I did once go through the Evo code once a long time ago and changed all direct references to /manager/ to a variable. It wasn't particularly difficult. Then it just needed a single line $manager-dir = '/myhost/www/mydomain/hidden" and if your site was in /myhost/www/mydomain/public_html/ then it was good. The only thing MODx ever needs to write to in the /manager/ folder is the config.inc.php file on installation. That could be written to a directory in the web root and manually moved if necessary, and the whole manager location made read-only.
Either a single line in the index.php files to indicate the location, or a single Revo-style config file with a single line is all that's needed. And instead of an ordinary PHP file, that file can be a non-executable PHP ini-type file, or an XML file, and use any number of file-parsing functions rather than including the file. The one-line location to the manager's location could be a JSON encoded string, and the content of the file very carefully validated before anything is done with it.
Cache files are another weak point, but they could also be written outside of the web root, at least as long as the server is configured to allow that. But as far as that goes, anybody who is concerned enough about security to want to do this in the first place won't be on the typical shared hosting.
Snippets, modules and plugins can be stored anywhere, as can templates, images and files. They just need to be written so that there aren't any hard-coded references to their actual location.
-
- 222 Posts
I think the location can be managed during the install process and the location should be part of the configuration.
And the configuration is stored in a .ini file (yes Susan, I decided this better, because of your arguments
).
In the end it is possible that there are only the index.php and index-ajax.php as bootstrap.
Even the inclusion of the configuration file can be changed during the installation process.
Gone away and found a better place to stay
-
- 1,624 Posts
Hi,
just my 2 cents. Considering the fact that (if I remember correctly) Evo will be switched to jQuery UI we should try to build the theme to be compatible with it.
I'm won't be able to help a lot in the next 2 months(vacation + moving) but I will keep an eye on the project.
Has there been a decision in keeping the frames or not?
Thanks
-
- 1,098 Posts
Yes, the theme is going to be developed with jQuery and jQuery UI.
I would like to keep the frames, for two reasons:
1. With frames we can keep Evolution light and avoid building an heavy AJAX application.
2. With frames it is very easy to add external pages to the manager.
-
- 1,624 Posts
Than I would say we start converting the top frame to jquery ui, continue with the tree and later the main frame.
Unless some takes over I will start one of these (probably the top frame) when I'm done with my move.
The Tree actually should get extra thought. Some way of paging or lazy-loading individual branches that are too long, in particular. Perhaps something besides a tree?
-
- 1,098 Posts
That's under development, I think that jstree is perfect, it has all we need: lazy-loading, drag&drop, creation of folders on the fly and context menu.
If the tree is too long, the only solution I can think of is to display the resources in a table, but that could confuse the user.
-
- 222 Posts
At the moment I agree with going with frames, I've to many modules, that are working as backend applications.
With up to date browsers (of course not IE lower than 9), this is possible with HTML 5 and iframes inside a div element.
jsTree does it, at the moment. But I'm also missing a tree with pagination, haven't seen any out there, no matter, if it is on jQuery or not.
On the design, I would also recommend using UI styles, because this makes it easy for the end user to have a choice and for us, to implement it.
Is some in here with experiences in JavaScript unit tests?
Gone away and found a better place to stay
☆ A M B ☆