Let’s say we have url slug like this
personal-loan/partners/gdf/gdf-personal-loan-test

and in the database we have post with post_name called personal-loan-1

Querying to DB will be good but will problem on query_var.. because in parse_request function you have code to replacing all request with original_url (from column post_name)

so for the current version the output will be like this
personal-loan-1/partners/gdf/gdf-personal-loan-1-test

but what i expected is something like this
personal-loan-1/partners/gdf/gdf-personal-loan-test

so my opinion is it will be good just replace when the value are exactly same

I am not a coder – anyone have a method to stop this conflict so I can keep my existing Event Manager Plugin as well as My Calendar Pro?

Here is the info from the calendar developer:

“That plug-in is creating a taxonomy called ‘event_category’. My Calendar has a parameter called ‘event_category’ that’s submitted as part of the event submission form. When WordPress parses the query to identify the right page, it’s noting that taxonomy and thinking that the My Calendar parameter is telling it to look for pages that are in that taxonomy – but there aren’t any.

The problem is that when rendering the submit-events page with the form POST set, the ‘event_category’ field is triggering an incorrect page query.

To fix this, you need to prevent WordPress from considering that parameter in that context.

You can probably do this by adding an action to change ‘parse_request’, and return a $query object that eliminates ‘event_category’ from consideration when parsing the permalink routes. This might be a useful article for you: https://roots.io/routing-wp-requests/

I don’t know *exactly* what you’d need to do for this. It’s an irritating problem, because neither plug-in is doing anything truly wrong; but because they’re using the same variable, WordPress is getting confused.”

So I noticed something with your plugin, on the file restricted_site_access.php line 120

public static function restrict_access( $wp ) {
		remove_action( 'parse_request', array( __CLASS__, 'restrict_access' ), 1 );	// only need it the first time
...

You remove the action hook ‘parse_request’ from within the function hooked, I understand this is to make the function to be called only once. But this breaks any hook to parse_request with a lower priority than yours. Since you are removing your function from the global $wp_filters (remove_action) this makes the iterator on wordpress to stop any calls to functions hooked to the parse_request with a priority above 1.

I would suggest using a static variable in your class instead of removing the hook. Hope I made myself clear, if you need further details let me know.

https://www.ads-software.com/plugins/restricted-site-access/

i enqueue the pseudo script so that it shows up in the header

function kia_wp_head() {
  wp_enqueue_style('dynamic', get_bloginfo('stylesheet_directory') . '/admin/ . '?my-custom-content=css');
}
add_action('wp_print_styles', 'kia_wp_head');

and then my custom parse request, which i dont think ever gets called… or if it does isn’t adding changing any CSS:

function my_custom_wp_request( $wp ) {
    if( isset($_GET['my-custom-content']) && $_GET['my-custom-content'] == 'css'  ) {

        # get theme options
        header( 'Content-Type: text/css' ); ?>

body {
    background-color: <?php echo 'red'; ?>
}

<?php
        exit;
    }
}
add_action( 'parse_request', 'my_custom_wp_request' );

any insights will be much appreciated.

Is there ANY way to tell wordpress that the present request does not need post data from the database because a plugin “got it covered”?

I’m programming a plugin that provides a rather large form. I created custom rewrite rules, registered add’l query_vars, hooked into the init action and the rewrite filter, but wordpress pulls posts from the db because I could not find a way to prevent this.

Example:

• I created the custom rewrite rule ^/myplugin/form1/?$ and mapped it to index.php?myplugin=form1
• Then, I hook into the init action in which I add the query_var myplugin (see rewrite rule)
• In addition, I hook into the rewrite filter. That way I can determine whether the present request has the myplugin variable (if so, I do something).
• From here, there seems to be no way to stop any further processing by wordpress. WordPress always makes its four to seven db queries which are a waste in this case.

Anyone? Thanks!

I’m starting some research to add a new feature to my Yet Another Related Posts Plugin. The idea (briefly) is that if there are any cross-postings from one post to another, it obviously should be returned as a related post.

In order to do this, however, I must take all anchor href’s in the content, check if it’s in the blog’s path and, if so, lookup the post ID based on the post URL (most likely permalink, but not necessarily).

I started looking at the Query Overview and the various classes/methods it references. What I’ve learned is:

1. WP objects run all the redirect code:
2. parse_request() gets the appropriate vars based on the permalink structure;
3. build_query_string() builds the (surprise!) query string;
4. and you enter this into query_posts().

However, I would like to run this on an arbitrary URL, while parse_request() is hard-coded to the $_SERVER vars. Sure, I can copy this code and make my own version of WP with a generic parse_request() method, but I don’t want to have to update this code with every WP version in the future that may change the way these redirects are done.

Does anyone know a better way to take a URL and find the appropriate post? Of course, this needs to work with whatever permalink structure the user has defined, as this is a public plugin.

Any hints or ideas would be appreciated! Thank you in advance!

mitcho