brownoxford

I’m seeing similar issues with text, audio and video widgets after a 4.8 upgrade. These all work fine with this plugin disabled, and even when enabled the widgets work fine on the Appearance -> Widgets page – they only display the broken behavior when editing a Post or Page.

Hi Lasano,

I understand your request and am planning to add that feature in the next release. I was coming at it from a different angle, (I want post pages with excerpts to be indexed by search engines), but I think the results will suit us both.

Great, glad you were able to work out a solution!

Making sure your query string parameters are url-encoded is less of a “workaround” and more of a “best practice”.

The issue you are seeing is coming from core WordPress code; when a user is sent to wp-login.php with a “redirect_to” query string parameter, WordPress will redirect the user to the url given by “redirect_to” after they successfully log in.

Prior to performing the redirect, WordPress will sanitize the redirect target in the wp_sanitize_redirect() method (located in wp-includes/pluggable.php). The following preg_replace is what is stripping your at-sign:

$location = preg_replace('|[^a-z0-9-~+_.?#=&;,/:%!]|i', '', $location);

It sounds like you are collecting a user’s email address in one place, and re-displaying it to them in another. Is it possible for you to hook into that process and ensure that the email address itself goes through urlencode() prior to being inserted into the href?

Hi Darren, have you tried replacing the @ with %40 in your link?

According to RFC3986, the “@” is a gen-delim and must be percent-encoded when present in query strings.

See https://tools.ietf.org/html/rfc3986#section-2.2

–Chris

I tried to reproduce this, but the only issue that I could find is that it is invalid PHP (when using alternative syntax for control structures you can’t omit the closing ‘endif;’, ‘endwhile;’ etc.

If I updated the PHP so that it parses correctly, I was not able to see your error. Are you still seeing this problem? If so, can you paste the exact code you have in place?

There aren’t any permission restrictions in place in the plugin that should be preventing this. I was able to add an “Editor” test user to my development installation and saw the Member Access meta box on both post and page editing screens.

Google (or any other search engine for that matter) will see the same thing as a non logged-in user. Unfortunately, there currently isn’t any secure way to have google see the post content, but have users be redirected since it would be easy to spoof user agents etc. to pretend that you are google and not a normal user.

It might be possible to add a feature which would show a fairly trimmed down page to search engines, maybe only containing the post title and excerpt. Is that something people would be interested in?

This was fixed in release 1.1.4

This issue was resolved with release 1.1.4

Hi Ami, this issue was fixed in the latest release, v1.1.4

This issue will be fixed in the next release. In the meantime, you can access the settings page from the link in the Settings menu on the left hand side in the admin area.

Thanks for making this fix public redgibson, the settings page will be fixed in the next release. In the meantime, also note that the link in the Settings admin menu does still work.

Check your wp-config.php file and make sure that you have the correct value for DB_CHARSET. Older versions of WordPress used ‘utf-8’, but it should actually be ‘utf8’ on newer versions of MySQL. The database install portion of this plugin attempts to use the DB_CHARSET when creating the tables, so if it is invalid, tables won’t get created.

I overcame this issue with the following steps:

1. Update DB_CHARSET value in wp-config.php
2. Deactivate and delete the AdRotate plugin
3. Manually remove the wp_options record for ‘adrotate_db_version’ (the uninstall fails to do this).
4. Re-install AdRotate

I agree, this has been changed in v1.1.3

Thanks!

–Chris