www.domain.com/DOCID

This could not be caused by the fix above. But only if you just changed the lines in the commit and did not replace the whole document.parser.class.inc.php …

Hello,

I've encountered this same problem and was able to fix it by replacing the released document parser with the one over at GitHub. Thanks for the help Jako. I just have one question, since I'm now working with a version of the parser that is "in development" but the rest of my MODX install is still the 1.0.12 release, will it be any less stable?

Testing this with public release of Evolution 1.0.13 - it still returns 404 when inserting document from QuickManager+:


MODX configuration


Anyone reviewed final 1.0.13 release after linked commit?
https://github.com/modxcms/evolution/commit/63856c833e1ba9d02cac1f6fa68bac20144f0b25

Don't think that this commit breaks QuickManager, but I did not have checked that.

It just allows the use of an id as alias (in that case $this->documentListing[$this->documentIdentifier] is not found) that is somehow not treated right by cleanDocumentIdentifier. Does it work if you remove the else branch? But the documentMethode is changed to 'id' afterwards and documentIdentifier should be an intval then. [ed. note: Jako last edited this post 10 years, 1 month ago.]

Quote from: Jako at Mar 18, 2014, 10:08 PM

It just allows the use of an id as alias (in that case $this->documentListing[$this->documentIdentifier] is not found) that is somehow not treated right by cleanDocumentIdentifier. Does it work if you remove the else branch? But the documentMethode is changed to 'id' afterwards and documentIdentifier should be an intval then.

Ok, I'm preparing Vagrant MODX setup to start debugging this locally. In the meantime - does opening address

works for anyone upgraded to 1.0.13 ? Just trying to eliminate my environment specifics (like subdomain, renamed manager folder etc.)

The 1.0.13 code of cleanDocumentIdentifier allows id based document identifiers in alias path mode only if the alias path to the parent is set right in my opinion. I think this is a good option to hide documents from direct access, so my commit should be better reverted or only be active in a sort of debug mode.

The QuickManager issue will not be better with or without that. That should be a url generating thing inside of QuickManager.

QuickManager issue aside, are you saying that in 1.0.14 or whatever is next, www.domain.tld/45 won't work? or will you add an option to the MODX config settings to allow this kind of url?

An option to turn it on or off would be great. I somehow doubt that I'm the only one out there that uses that format of url with MODx.

An option to turn it on or off would be great.

Will be done that way.

Thanks!

Quote from: Jako at Mar 19, 2014, 11:13 AM

The QuickManager issue will not be better with or without that. That should be a url generating thing inside of QuickManager.

Understood, so is it advisable to open QM+ issue on Github - because that's how QM+ formats redirects on resource insertion from frontend toolbar?