more robust inclusion and rewriteUrls function

Hello

I’ve posted a bug about Ditto (FS#715) ... but in act it’s all MODx that should be rewritted ...
Well ... the genral problem : When using MODx theire is no wrapper like joomla does ... so, if I want to intagrate another programm (forum ...) I have to rewrite that other stuff to include MODx part (menu, some chunked box...)

For doing so, I do use MODxAPI ... nice but ...
If my code isn’t placed in the root dir ... it simple doesn’t work.
first : Ditto can’t include its languages files nor it’s functions.
If I correct Ditto ... then it’s MODx’s DBapi that goes wrong...

ok ... so I have to place EVERY developpement I do for MODx inclusion into the root dir (it’s not nice... that should be improved I think... althougt it’s not urgent as theyre is a way for doing without)


Then come the second problem... which is a blocking bug :
My menu (or other stuff) is called from a page that is in forum (or something else) ... and all link are relatives...
that mean that my link toward page.html (I do use pretty url ... but As I4ve read the code, it will be the same thing without it) that should be http://www.mysite.com/page.html will be http://www.mysite.com/forum/page.html

When I will have enough time, I will try to correct that thing in document.parser.class.inc.php, comparing the path the call come from with the site_url and prefixing the $out with the correct value for making it point.
I think it should be nice to include it in very next release.

Hello piwaille,

If in fact we’ve got a blocking bug in part 2, as it certainly sounds like we do, and you get a fix done quickly, we’ll get it in the 0951 release which is primarily being done for adding language files (Russian, Japanese and Dutch so far). Should be out this week.

Quote from: piwaille at Dec 11, 2006, 04:32 AM

I’ve posted a bug about Ditto (FS#715) ... but in act it’s all MODx that should be rewritted ...
Well ... the genral problem : When using MODx theire is no wrapper like joomla does ... so, if I want to intagrate another programm (forum ...) I have to rewrite that other stuff to include MODx part (menu, some chunked box...)

Good suggestion, only it has already been rewritten from scratch over the past year; completely OO, based on solid design patterns and principles, and in a way you can use the API anywhere in a consistent fashion (and without the MODxAPI add-on from the repository). And integrating external applications, especially in a language like PHP, is anything but trivial anyway, even with proper "wrappers" as you call them. But that’s not to say it isn’t something MODx can make easier to accomplish.

Quote from: piwaille at Dec 11, 2006, 04:32 AM

For doing so, I do use MODxAPI ... nice but ...
If my code isn’t placed in the root dir ... it simple doesn’t work.
first : Ditto can’t include its languages files nor it’s functions.
If I correct Ditto ... then it’s MODx’s DBapi that goes wrong...

FYI, moving forward, the DBAPI will be deprecated in favor of using PDO, and the MODxAPI will not be supported (or needed) in future major/minor releases (does not include patch releases of 0.9.5, e.g. 0.9.5.1, etc.). It was an add-on convenience provided so you could accomplish things now that will be accomplishable using the new core API in MODx 0.9.7+. Feel free to contribute additions or changes to that add-on to make it work how you need it to.

Quote from: piwaille at Dec 11, 2006, 04:32 AM

ok ... so I have to place EVERY developpement I do for MODx inclusion into the root dir (it’s not nice... that should be improved I think... althougt it’s not urgent as theyre is a way for doing without)

This will also be solved moving forward, as the core can be located anywhere and you’ll have much more robust control over configuration settings like paths.

Quote from: piwaille at Dec 11, 2006, 04:32 AM

Then come the second problem... which is a blocking bug :
My menu (or other stuff) is called from a page that is in forum (or something else) ... and all link are relatives...
that mean that my link toward page.html (I do use pretty url ... but As I4ve read the code, it will be the same thing without it) that should be http://www.mysite.com/page.html will be http://www.mysite.com/forum/page.html

When I will have enough time, I will try to correct that thing in document.parser.class.inc.php, comparing the path the call come from with the site_url and prefixing the $out with the correct value for making it point.
I think it should be nice to include it in very next release.

I am not clearly seeing the problem, other than the external menu should be handled by your MODxAPI extension that you are using or a dedicated component to build the menu with the proper paths. I think this is a perceived limitation based on your choice to use this add-on, and it should not affect the document.parser at all to solve it. In fact, MODx 0.9.5 development is basically closed except for critical bugs (which I do not see this issue as) and feature additions that will not affect existing components that use the current API’s. The new MODx 0.9.7 core will already solve this and there is not a single line of code in common, so I think maybe it would be best to wait for the 0.9.7 preview later this month, and see what it brings to the table. You’ll be able to use something called Contexts to control core settings for API calls that must exist in specific physical locations outside of MODx managed content, like your forums. For now, not sure how MODxAPI add-on works out the URLs based on the root of the code you are integrating now, but sounds like it’s not doing it in a way that an external API should.

thanks for your answer

iwill have to read it some more times to be sure to understand
but I’ve understood that next version while resume de (big) evolution of MODx.
I’ve just written some snippet much too early (I think to the DBapi rewriting toward a full OO model)

I’m happy to see that I’ve made the right choice thinking MODx will be THE CMS/FMS ...

I am not clearly seeing the problem, other than the external menu should be handled by your MODxAPI extension that you are using or a dedicated component to build the menu with the proper paths.

When I want to integrate (for example) my forum, I want it to display the menu, the last blog entry ...
Each time I do use a snippet that creat links (Ditto, DropMenu...) they create link :
so the link is relative from ... where it is shown (despite the way for building it)

So I have 2 choices :
* modify each every chunk, snippet et other stuff for putting a single / before the [~id~] ... this is very simple but I can’t use any search/replace tool as it is all in database.
* modify the single rewriteUrls function in document.parser.class.inc.php file. It can easily be done. One only modification solve all my problems but I will have extra work eachtime upgading my core