3

We have added a custom rewrite_rule to our site to allow for a pretty inbound link to be parsed and handled properly. Links are constructed as domain.com/meetings/faculty/someIDnumber

add_action( "init", "pleasing_permalinks" );
function pleasing_permalinks() {
    add_rewrite_tag( '%hash%', '([^&]+)' );
    add_rewrite_rule(
        'meetings/faculty/([^/]+)/?$',
        'index.php?p=1598&hash=$matches[1]',
        'top'
    );
    //flush_rewrite_rules();
}

Rewrite Analyzer approves of the above but when we test with actual links in the browser, the embedded ID number is not preserved. What are we missing here?

3
  • +1 for commenting out the flush_rewrite_rules, massive performance drop on 'init'
    – Tom J Nowell
    Commented Mar 29, 2013 at 22:52
  • 1
    are you testing domain.com/faculty/someIDnumber instead of domain.com/meetings/faculty/someIDnumber ?
    – birgire
    Commented Mar 30, 2013 at 11:41
  • No, sorry. That's a speed-typing omission. We are testing the correct paths.
    – JCL1178
    Commented Mar 31, 2013 at 2:04

3 Answers 3

7
+150

If faculty is a child page of meetings, the rule should be:

add_rewrite_rule(
    'meetings/faculty/([^/]+)/?$',
    'index.php?pagename=meetings/faculty&hash=$matches[1]',
    'top'
);

pagename=meetings/faculty instead of p=1598

EDIT- or alternately:

add_rewrite_rule(
    'meetings/faculty/([^/]+)/?$',
    'index.php?page_id=1598&hash=$matches[1]',
    'top'
);

page_id=1598 instead of p=1598

2
  • 1598 is the page ID in question. Are you saying that we cannot use the direct ID as index.php?p=XXXX in the rewrite?
    – JCL1178
    Commented Apr 1, 2013 at 17:28
  • 1
    you can't use p= for a page, use either the path or page_id=.
    – Milo
    Commented Apr 1, 2013 at 17:36
0

Have you tried using the first index rather than the second?

'index.php?p=1598&hash=$matches[0]',

Arrays in PHP start at 0 not 1

2
  • <slowly and repeatedly slams head into desk>. I hope that isn't it. That's too easy
    – JCL1178
    Commented Mar 29, 2013 at 22:55
  • 5
    That's not it. According to the Codex (codex.wordpress.org/Rewrite_API/add_rewrite_rule) "NOTE: When using $matches[] to retrieve the values of a matched URL, capture group data starts at 1, not 0."
    – JCL1178
    Commented Mar 30, 2013 at 2:08
0

Just tested your code on a clean WP installation and was able to get the variable with:

echo $wp_query->query_vars['hash'];

Wordpress Codex - add_rewrite_tag:
Note that using $_GET on a rewritten URL will not work, even if the rewrite includes the querystring variables. You must use $wp_query.

Edit: As written in the correct answer 'p' must be replaced with 'page_id' to be able to keep the variables when redirecting to a post of type 'page'.

2
  • the issue was that WordPress will redirect and strip the extra parameter from the URL if your rule doesn't point to a valid object, in this case p= assumes the post post type while the desired post was of type page. it's not a matter of how to access the query var if you're redirected to a URI that no longer contains that query var.
    – Milo
    Commented Apr 4, 2013 at 22:09
  • Ah I see. I didn't understand the problem then. Thx for clearing that up!
    – Kim
    Commented Apr 4, 2013 at 23:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.