Thread

Ack!! I’m supposed to go live this morning with a new site and just discovered that as a result of last-minute stuff last night, all weblog pagination is broken.

I am using mod_rewrite to force lowercase letters…naturally, that big capital “P” that EE creates for pagination links creates a problem. But the thing is, nothing I’ve done thus far to try to get around it works. (The only other thing that would be affected is categories with a uppercase “C,” right? Thankfully, I’m not outputting that stuff.)

—tried find/replace on the pagination links—>find P | replace p
—tried altering mod_weblog.php line 3151 $PGR->prefix   = ‘P’;

It looks like there are a lot of other dependencies in that file where I’m seeing a hard-coded uppercase P. I guess that would explain why my attempts failed.

Is anyone awake? Can someone help me get this squared away?

EDITED TO ADD: No wait! Crap! I can’t simply lowercase it because I have conditionals going on that essentially say “if segment_2 begins with a P, do this”...and I’m bound to have a url title that begins with a “p.” Okay, what about changing the pagination prefix to something totally unique or not likely to appear in that position otherwise? How ‘bout an “x”...? OMG I’m just rambling here.

Take out the mod_rewrite to get rid of uppercase. What were you needing that for?

There is a third party addon http://devot-ee.com/add-ons/md-detect-page-type/ that might help with detecting the page type..

Are users manually typing in urls with capital letters?

I need to force lowercase to ensure that all my segment-based conditionals function properly.

Example: if segment_2 == “foo”, stick this in the sidebar…“foo” is not the same as “FOO”

Um, yes…users have been known to type in camelcase URLs

Um, hello? New site…trying to launch…looking extremely stupid to client at this point…

You guys tout the magic of segments and conditionals when using EE but no one seems to mention that for those of us on Apache/Linux, URLs are case sensitive which means a conditional that relies on a segment being some specific text will fail spectacularly if the enduser types it in himself with the CAPSLOCK key on (that’s just an example…I mean, there are definitely other scenarios). So it took me 6 years to realize that all my EE sites suffer from my ignorance about this and I’m just trying to launch a new client’s web site without this pit of doom waiting in the wings to spring to life. (Of course, then I have to go back and fix all the other sites.)

My fear is that if/when you do get back to this question, you’ll shunt it to never-never land aka the Community Help forum. If that’s the case, maybe you can put it right with the question I posted there three weeks ago about this specific issue and got no responses. I don’t think forum use is anything like it used to be and I also suspect that I can’t possibly be the only EE user who completely overlooked that this problem can and does occur. Am I really the only person concerned about this?

Hi, municipal. We do have a solution for you that may work for you..

See: http://php.net/manual/en/function.strtolower.php

Turn of PHP in templates, in either input or output mode depending on what you need to ensure that your conditionals are dealing with lowercase letters. It’ll add some processing time.

As far as other people running into this problem go, I honestly don’t remember it coming up. Apache servers are case sensitive.

But you are correct, there are those clients that don’t realize their capslocks are on.

Will that work for you?

Turn of PHP in templates, in either input or output mode depending on what you need to ensure that your conditionals are dealing with lowercase letters. It’ll add some processing time.

Huh? I want to ensure that my conditionals work irrespective of URL case.

I know Apache URLs are case sensitive—that’s the whole point here.

Can we perhaps go back to my original question regarding mod.weblog.php…and mod.query.php because that, too, affects weblog pagination. It’s not the route I want to take but you’re making it sound like I am totally off the wall with this issue and that I’m the only one. If I’m the only one, it’s because no one else has noticed. Anyone who uses a conditional to load in a sidebar or a javascript based on a segment of the URL being a specific lowercase word is in for a surprise (depending upon their server environment of course).

Hey municipal–

I really wouldn’t suggest modifying core files here. We can’t support it, and you would need to protect those changes anytime you performed an upgrade. It’s really not the way to go.

Instead, Sue’s suggestion is really the best thing. Allow your URLs to be case-sensitive like they are by default, and that will take care of your pagination issues.

Then the only problem we’re left with is the potential for your client to enter things into the URL with the wrong casing. To defend against that possibility, turn on PHP in the template and set it to PHP on Input.

Then, instead of doing something like this:

{if segment_3 == 'joe'}

    Hey Joe, where you goin with that?

{/if}

You’ll do something like this, taking a cue from Hop Studios’s comment on the URL Segment Variables page.

<?
$this->EE =& get_instance();
$seg3 = strtolower($this->EE->uri->segment(3));

if ($seg3 == 'joe') {
?>
    Hey Joe, where you goin with that?
<? } ?>

This way, if your client types in either ‘JOE’ or ‘joe’ or ‘JoE’ or ‘JOe’, etc… PHP converts it to ‘joe’, and then evaluates the conditional using that value instead.

Does this help?

Kevin

I have implemented similar PHP to deal with this, thank you for your thorough response. But I also came across something which I’m not clear on. It looks like pages produced via the Pages module will 404 if entered in all caps (or a combination thereof). The 404-ing doesn’t appear to be an Apache thing but rather, an EE thing. Any ideas on how to address this? (I’ve been a long time EE user and when strict URLs was introduced, I was so entrenched already that I just never really “got” it. DO they have any role in fixing this?)

Hi municipal,

The Pages URI will work as long as what you enter is a valid as a URI. This means that the URI can be mixed case and only that exact version will work. Strict URLs are described in the documentation but they not directly related to any URI that is in caps or mixed case. It should work as long as the URI is valid i.e. assigned to an entry. Does that help?

Cheers

Greg

Glad to see someone still monitors this forum.

So, how do I intercept, say, a request for a URL in all UPPERCASE that is specified on the backend via the Pages module to avoid the 404-ing?

Hi municipal,

You can intercept any request using the sessions_end hook and modifying the $IN global. However, I would strongly recommend not doing this if at all avoidable. I’m not really following your intent or requirement here; if an entry’s Pages URI was entered as uppercase or mixed case then you’d need to know what that was so that you could properly rewrite any frontend lowercase URI appropriately. This of course would involve additional DB requests. If it’s the case that the primary issue here is the client’s misunderstanding of what is and is not appropriate as a URI then I would try and tackle that at source and try and provide additional training or documentation.

Cheers

Greg

I’m simply looking for a way to avoid an error page being served up if someone tries to reach a URL with the caps lock key on.

Hi municipal,

Are you talking about your clients or general site visitors? Your site will respond exactly like every other site on the Internet. You can try and second guess visitors by either using mod_rewrite or by modifying the request with an extension but I think this will be prone to error so I would not recommend it. There is no reason why you can’t create a fairly complex 404 page that suggests viable URLs or shows a site map if a user lands there by accident.

Cheers

Greg

municipal,

Were you able to figure out a solution? I to am running into this exact issue. I want to force lowercase urls for a number of reasons, but am hitting a wall with the pagination parameter. I find it a little odd that we are stuck with the obscure P{num} in the first place, and am more concerned now with this lowercase URL bug. I follow your thoughts on why you want to correct peoples pages instead of just giving them 404’s. Does anyone have a solution/suggestion for this?

If you haven’t found a solution yet, here is a rule that I added to my htaccess that will allow pagination to work

RewriteCond !P[0-9]* [NC]