Hey all,
I’ve been using .htaccess Generator without incident for a long time, but then custom Pages URLs stopped working.
I can of course get them working if I manually add the URLs to the .htaccess template file that Generator uses, after I create the Pages, but I’d like to not have the client have to do this. {ee:templates} continues to work.
The issue seems to be that {ee:pages} doesn’t properly ‘write in’ the pipe-delimited list of Pages URLs. We recently updated to version 1.6.9 of EE, and I know that in the Version Update Notes for 1.6.9, there is some talk about extensions that use methods for calling Pages’ URLs as requiring an update, since the storage method for pages has changed internally.
Getting {ee:404} to work is less of a priority for me, since that never changes on my site (and isn’t under the control of the client) and I can manually add it in if it ever does. But I’d really like to get {ee:pages} working to keep it all seamless for the client. Any ideas?
Here’s Leevi’s code that seems to deal with ee:pages (and ee:404) in .htaccess generator (lines 552-579):
// replace pages
if(strpos($new_htaccess, "{ee:pages}") !== FALSE)
{
if(($pages = $PREFS->ini('site_pages')) !== FALSE)
{
$page_roots = array();
foreach ($pages['uris'] as $page_id => $page_url)
{
if(substr($page_url, 0, 1) == "/")
{
$page_url = substr(trim($page_url), 1);
}
$parts = explode("/", $page_url);
if(isset($parts[0]) === TRUE)
{
$page_roots[] = $parts[0];
}
}
$new_htaccess = str_replace("{ee:pages}", implode("|", array_unique($page_roots)), $new_htaccess);
}
else
{
$new_htaccess = str_replace("{ee:pages}", "", $new_htaccess);
}
}
$new_htaccess = str_replace("{ee:404}", $PREFS->ini("site_404"), $new_htaccess);Can anyone shed some light on how this code might not be working as intended with the new 1.6.9 Pages URL storage structure?
Cheers all.
R o B
{ee:pages} broke for me too in EE 1.6.9 but {ee:404} is still working for me.
I have fixed the {ee:pages} issue for my install.
In the block of code Oxygen referenced above, modify a line (558 I think):
foreach ($pages[1]['uris'] as $page_id => $page_url)The change is just to put [1] between $pages and [‘uris’]. This is because the pages array has got a new dimension in EE 1.6.9 to represent the site id. See info: http://expressionengine.com/docs/installation/version_notes_1.6.9.html
So this fix won’t work for MSM sites as is - you may just need an extra loop to go through the site ids in the array instead of just hard coding [1]. I’ve never used MSM myself.
Hopefully this fix will work for others - let me know if you find any issues with it.
Thanks to both Oxygen & tidy!
Just upgraded a borked the site pretty thoroughly. Found this thread and it fixed it right up!
I am also running MSM, and can confirm that the following works, as the site_id is already available to the extension:
foreach ($pages[$PREFS->ini('site_id')]['uris'] as $page_id => $page_url)This will allow you to safely get this working for all of your MSM sites.
Cheers,
Ira
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.