SITEMAP_APPROVE_IMMEDIATELY
Permalink
I've come across an issue with this new constant in 5.6.1 - thought I'd see what other peoples thoughts were...
We currently aren't using Workflow, I should point out, so I'm not fully up to speed on Workflow.
When this constant is set to true and a user adds a new page via the sitemap, then new page is not approved and is not run through workflow. Fine. That sounds like what I want. See line 1131 of startup/process.php for the code.
However, as the page is not approved, it seems like no path is added to the PagePaths table for it and if the user then clicks on the page in the sitemap and selects visit, they get stuck in a redirect loop.
I've adjusted the code at line 1131 to the following:
So the page is run through workflow, and is approved, and then the deny() method appears to 'unapprove' it quite nicely.
It's a bit of a hack and not really what I want to do. Just wondering if there was a better way, or if this needs to be addressed in the next release?
Thanks,
Jon
We currently aren't using Workflow, I should point out, so I'm not fully up to speed on Workflow.
When this constant is set to true and a user adds a new page via the sitemap, then new page is not approved and is not run through workflow. Fine. That sounds like what I want. See line 1131 of startup/process.php for the code.
However, as the page is not approved, it seems like no path is added to the PagePaths table for it and if the user then clicks on the page in the sitemap and selects visit, they get stuck in a redirect loop.
I've adjusted the code at line 1131 to the following:
if ($cp->canApprovePageVersions()) { $pkr = new ApprovePagePageWorkflowRequest(); $pkr->setRequestedPage($nc); $v = CollectionVersion::get($nc, "RECENT"); $pkr->setRequestedVersionID($v->getVersionID()); $pkr->setRequesterUserID($u->getUserID()); $response = $pkr->trigger(); if (!SITEMAP_APPROVE_IMMEDIATELY) { $v->deny(); } }
So the page is run through workflow, and is approved, and then the deny() method appears to 'unapprove' it quite nicely.
It's a bit of a hack and not really what I want to do. Just wondering if there was a better way, or if this needs to be addressed in the next release?
Thanks,
Jon
We do have URL_REWRITING_ALL also turned on.
Could this be the issue? Trying to redirect to a pretty url and then bouncing around because there isn't one?
Jon
Could this be the issue? Trying to redirect to a pretty url and then bouncing around because there isn't one?
Jon
Hello,
Thanks for getting back to me. When you hover "Visit" in the sitemap what link are you getting for that?
It should look like the cID one above. Some Add-Ons and code in the wild attempts to get the Page Path to do redirects and other things. Can you think of anything that might be hooked into on_start() or a Page event that might be trying to do something like that?
At what point(if ever) do you see a link be anything other than the one I showed above?
Best Wishes,
Mike
Thanks for getting back to me. When you hover "Visit" in the sitemap what link are you getting for that?
It should look like the cID one above. Some Add-Ons and code in the wild attempts to get the Page Path to do redirects and other things. Can you think of anything that might be hooked into on_start() or a Page event that might be trying to do something like that?
At what point(if ever) do you see a link be anything other than the one I showed above?
Best Wishes,
Mike
Ok, I'm gonna have to do some more digging when I get back into the office tomorrow. On our main site, when we try and go to any index.php?cID=xxx link, it will always try and loop us back to the pretty url. Even if that page is not approved. Which causes a redirect loop.
However, just tested on a clean install (as I should have initially I guess :-S) and it worked as expected.
So clearly we have something else getting in there and causing the issue. I'll dig around and let you know what I find, but I'm confident the issue is our end and not yours now...
:)
Cheers Mike,
Jon
However, just tested on a clean install (as I should have initially I guess :-S) and it worked as expected.
So clearly we have something else getting in there and causing the issue. I'll dig around and let you know what I find, but I'm confident the issue is our end and not yours now...
:)
Cheers Mike,
Jon
Ok,
Thanks for looking into this with me. I'm going to try a couple more things tomorrow morning as well. Let me know if you uncover anything. I will do the same.
Best Wishes,
Mike
Thanks for looking into this with me. I'm going to try a couple more things tomorrow morning as well. Let me know if you uncover anything. I will do the same.
Best Wishes,
Mike
Hi Mike,
looks there was some code added to our site_post.php to go above and beyond what URL_REWRITING_ALL was doing. I've removed this as I'm really not sold on the fact that we need it and reverted process.php back to the original and it looks like we're all good.
If I come across any additional URL's that really should be re-written that aren't handled by URL_REWRITING_ALL, then I'll submit them separately, but I personally haven't seen any.
Thanks Mike,
Jon
looks there was some code added to our site_post.php to go above and beyond what URL_REWRITING_ALL was doing. I've removed this as I'm really not sold on the fact that we need it and reverted process.php back to the original and it looks like we're all good.
If I come across any additional URL's that really should be re-written that aren't handled by URL_REWRITING_ALL, then I'll submit them separately, but I personally haven't seen any.
Thanks Mike,
Jon
Hi Jon,
Thanks for getting back to me. Let me know if you notice some additional issues with URL_REWRITING_ALL and if you still want to enforce the redirect like that you can try something like this.
Haven't tested, but this should exclude pages that do not yet have a path set.
Best Wishes,
Mike
Thanks for getting back to me. Let me know if you notice some additional issues with URL_REWRITING_ALL and if you still want to enforce the redirect like that you can try something like this.
$view = View::getInstance(); $cObj = $view->getCollectionObject(); $path = $cObj->getCollectionPath(); $cID = $cObj->getCollectionID(); $cnt = new Controller(); if ($path || $cID === HOME_CID) { $cnt->redirect($path); }
Haven't tested, but this should exclude pages that do not yet have a path set.
Best Wishes,
Mike
What that block of code should do is approve that page. Before that happens that page does not have a Path set. This is by design.
The interesting issue about this is that the pages are linked from the sitemap by cID for example
Where exactly are you getting to a link by URL with the page slug?
Best Wishes,
Mike