• I have an otherwise working installation and am writing a new theme. I have friendly urls set to /%category%/%postname%/ and .htaccess setup. Everything works as I would expect, including links to pages, and pages with custom templates assigned.

    If I pass query string params in the url, they work just fine:

    /mypage/?foo=bar

    The minute I pass something like /mypage/?m=1, or ?year=2010, I get a 404 page instead. ?year=2009 returns the page.. ?year=2008 returns a 404.

    My htaccess is nothing more than:

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /~claco/wordpress/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . index.php [L]
    </IfModule>

    What’s going on here? Is there a set of reserved query string param names that influence the loading of the pages content entry, which causes the 404?

    I’m thoroughly confused.

Viewing 10 replies - 1 through 10 (of 10 total)
  • Beware, the default permalinks always work (including date archives), even if you have pretty permalinks enabled.

    Thread Starter claco

    (@claco)

    Which relates to my problem how?

    The minute I pass something like /mypage/?m=1, or ?year=2010, I get a 404 page instead.

    You are improperly using WordPress query strings with your pages. The WordPress reserved query strings can be seen in the default permalinks. As for the 2010 query giving a 404, I’d imagine that there isn’t a 2010 WordPress archive yet since it’s in the future.

    ?year=2009 and ?m=2009 both get you the 2009 WordPress archive. If you are using pretty permalinks, then /date/2009/ would get you the same thing.

    Thread Starter claco

    (@claco)

    The problem is, a) I’ve found no definitive list of reserved query string params, and b) Magic is bad.

    I have a single page template, and I want to use various query string params in custom code to control the behavior of different elements on that page. It seems silly that I have to play a guessing games about how I can write PHP and pass query string elements (just like I would do in any other web framework in the world). Why m and not month? Why year and not y? Just because the wordpress urls are friendly, doesn’t mean all use of the query string params for applications, plugis and custom code can’t be used. And since my custom permalink style doesn’t include %year%, it seems broken.

    Here’s the real example. I have a template called vulunteer.php, tied to the Volunteer page. That template displays the pages content and all is well. Now I added a block of code to pull a set of unrelate information form the database, and that code was going to look for the year and month query params to determine what information they were interested in.

    Worked fine for ?year=2009&month=3. The minute year went to 2010, or 2008, I get a 404. The minute I change my code to use ?y=2010&m=3, I get a 404 because WordPress is in love with the m param.

    That’s why I’m frustrated. I could understand if year is a reserved query string param, but then I would expect month to be reserved, not m.

    All in all, it’s a big fail in terms of expectations.

    Thread Starter claco

    (@claco)

    Also, using year/m to retrieve an archive on a Page (not a post, or a template for a category, multiple posts, etc) seems broken. It’s a single entry for a single page. Year should be ignored.

    I’ve found no definitive list of reserved query string params

    I haven’t either. There must be one somewhere, but I haven’t been able to find it in the Codex or by Googling.

    I had a similar problem related to forms and $_POST. It took me almost an hour to figure out that my form data was not showing up in the $_POST because I had used name=”name” and name=”email” in my input tags. Changing the tags to use name=”form_name” and name=”form_email” allowed everything to post to the page properly. I did not find this in the documentation, only mentioned in a couple of blogs as a potential solution to form posting problems. It would be great to see this issue explained and documented in the official docs.

    I’m also curious to see if this function is related to this issue:

    https://codex.www.ads-software.com/Function_Reference/form_option

    I just got this too, using “day” as a query string parameter. It would be nice to have a definitive list of reserved qs var names, but it’s not a big stumbling block. It took me 2 seconds to find a name that worked ??

    This is madness – there must be a list of reserved GET/POST params? I only found this thread after I sussed the behaviour myself.

    I’m using a Java plug-in which POSTs back to the page the vars a,i,k & m and the POST was obviously being greeted with the aforementioned 404.

    You can imagine how many blind alleys I went down and how long it took before I realised that it was the param ‘m’ causing the behaviour. It wasn’t 2 seconds.

    Perhaps ‘m’ stands for magic. Or mental.

    PMF

    There’s a list in the Codex here, admittedly not very easy to find, I stumbled across it by pure chance, and also not complete (‘m’ is missing for example):

    https://codex.www.ads-software.com/Function_Reference/register_taxonomy#Reserved_Terms

    the definitive list is here if you look at the content of $public_query_vars and $private_query_vars:

    https://core.trac.www.ads-software.com/browser/trunk/wp-includes/classes.php

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Reserved words/params list?’ is closed to new replies.