Peter

You’d have to modify the homeurl() functionality: https://wordpress.stackexchange.com/questions/298965/change-admin-bar-visit-site-url

Then you could use the redirect_to_front_page() function to return the correct URL.

Thanks!

A setting essentially solves the issue!

Every install is different, and often you do know the proxy IP addresses in the case where you’ve set up your own proxy with Varnish. But in any case, if the admin can decide to trust X-Forwarded-For, then that puts the power and responsibility in their hands.

I understand your concern with other IP headers. However, as it stands your plugin is not usable for a site behind a CDN or reverse proxy, because when a block is triggered, it will block everybody. REMOTE_ADDR is typically the IP of the CDN or reverse proxy. In such setups, if you check REMOTE_ADDR first, you will never check the other headers.

One way to address the concern of untrusted proxies causing a false positive is to have a list of trusted proxy IPs for which the X-Forwarded-For or Client-IP headers will be respected.

Thanks! I’ve released a new version with this fix as well as for all the other checkboxes in the plugin.

Yes, it is tested to work on WordPress 4.4.1

Yes, you can find old versions here: https://www.theblog.ca/wplogin-redirect

I’m not sure why e-mail servers would have a problem with a link in an e-mail. Or maybe it’s a new feature in the wp_mail function.

Obviously those links are important since they send the users to the correct edit paths. So as a quick patch you could replace all instances of:

get_edit_post_link( $pce_object->ID, false )

… with:

preg_replace( '(https?://)', '', get_edit_post_link( $pce_object->ID, false ) )

That will result in links without https:// or https:// in front, so they won’t be clickable.

I tested this on WordPress 3.9.2 and I had problems with one mail server because it was blocking URLs in e-mails. (To test this, you can comment out all lines in the plugin file with get_edit_post_link in them.) However, on another mail server it was going through fine, so I couldn’t find any issues related to the plugin actually sending e-mails (and for that it uses the standard wp_mail() function).

Perhaps a conflicting plugin is intercepting the transition_post_status filter and exiting, preventing other plugins from running in that filter.

Did you install the plugin at the network level and then activate it on a per-site basis? If so, I would suggested turning on WP_DEBUG (https://codex.www.ads-software.com/WP_DEBUG) to see what useful errors there are when you activate the plugin (which is when it tries to create the database tables).

Thanks for bringing that up. This issue should be fixed in version 2.8.1 of the plugin, as the delete action doesn’t check for a valid user anymore.

Sorry about that. Other than the issue about reaching limits around the number of form fields, I had also received feedback about how the previous interface was not intuitive for adding and removing rules. I am definitely open to design/layout suggestions and mockups. Also, something I always recommend if there are many rules to manage is to consider whether they can be consolidated into a single rule with a dynamic URL part.

There was a limit of about 333 user-specific rules with the default PHP settings. However, with version 2.8.0 of the plugin, this limit should be lifted.

Do all of your redirects follow a similar pattern involving the username? If so, you might want to consider building a single redirect rule using the special syntax [variable]username[/variable].

Hi,

See the “Custom ‘My Portal’ Link” section at the bottom of this page:

https://www.ads-software.com/plugins/peters-login-redirect/other_notes/

Hi,

Yes, there is some documentation on how to create your own variable in the “Custom variable parameters” section here:

https://www.ads-software.com/plugins/peters-login-redirect/other_notes/