Export with directory structure discussion

Have you all read the public thread: http://vertexworks.com/forums/index.php?topic=506.msg2800#msg2800


This is actually a very very good idea. Think of all of the sites that don’t necessarily update as frequently as blogs (most of them!). This could be a very effective way to set us apart from the competition.

It would certainly increase site speed monumentally and cut resource overhead. Customers could effectively have a subdir called /prod where Modx sits, and then export the structure to the root dir.

Does anyone other than me think this may be a good idea? Is this something anyone with any dev experience would want to throw their weight into to see if it could work?

- John

Well this is very similar to the publishing feature I propose back in the Etomite days and early in the MODx discussions. It works differently, keyed off on workflow and when a page is published, as opposed to cron or some other scheduler. I’ll see if I can dig up the description of how other mid-tier CMSs do it.

I agree that this is a very good feature to have. If someone can get at least the direcorty export feature working we could roll that out in TP3. The other features can be rolled out in TP4

Quote from: xwisdom at Jul 12, 2005, 01:53 PM

I agree that this is a very good feature to have. If someone can get at least the direcorty export feature working we could roll that out in TP3. The other features can be rolled out in TP4

I’ll take a stab at getting directory export working in TP3. I think we could then offer a module that followed the real-time workflow-based publishing system requirements separate from the core product. I think both approaches offer something to different audiences, and it makes sense as a module offering that exemplifies the MODx plugins and their ability to interact with system events.

Thoughts?

Awesome guys!

This could really add a ton of value added benefits to our product! Even the crappy CMS I am forced to deal with in my job has a publish feature like this, and we are paying through the nose for it.

This could be a great value added benefit that makes others take a good hard look at us once we release it!

Jason,

Good going man. I think is is a well needed feature indeed

John,

I agree with you 100%

FYI, before I can get the directory export feature working, I’m going to have to fix the Use Friendly Alias Path options, because currently, in my test environment, when I reference things by the absolute path from the root of the site, the parser is using the root of the webserver to find resources, and thus cannot find them since they are not necessarily in the root of the webserver. Users should be able to either reference things by relative path as usual and the parser take care of always using the site_url to build the actual path, or at very least, use this method with URL’s referenced absolutely so that pages outside the root can find the resources properly. Currently, all my content would have to be authored absolute to the web server root, which would change when going from test environment to production server.

so the <basepath> tag did not solve that?

Quote from: xwisdom at Jul 13, 2005, 02:18 PM

so the <basepath> tag did not solve that?

No, not really, and it was determined that this was also incorrect usage of the tag according to W3C standards. I’m wondering if there is a way to have the folders without changing the context of the parser when visiting a page nested in one of the folders?

I think the problem here is with SRCs and HREFs. Why not just have the parser rewrite the SRCs and HREFs that does not have "/" or a ".." to use $base_url or $site_url? the same should also apply to url() for css