How to fix Cloudflare and AMP Invalid attribute values

Posted on February 26, 2016 by Jeff Heck

The Problem: Google’s Webmaster Tools for Accelerated Mobile Pages says your pages are throwing errors like this:

Invalid attribute values: src=//cdn.ampproject.org/v0.js, href=//fonts.googleapis.com/css?family=Merriweather:400,400italic,700,700italic|Open+Sans:400,700,400italic,700italic

I am using the official AMP plugin created by WordPress’ company Automattic to make my site AMP usable so my pages will open in a mobile friendly format… and so Google will improve my site’s ranking – I hope!

I am also using a free Cloudflare account to improve speed and security. The problem is Cloudflare is not quite AMP friendly yet.

So far I have found 2 settings that I needed to change. There are other errors I still need to figure out, but I wanted to list the solutions I have found so far.

First change: Notice in the error above, it is showing the “src=//cdn.ampproject.org…” That really should be “src=http://cdn.ampproject.org…”. So where did the http go?

After doing the requisite disable all the plugins and reenable them one at time test, I found the culprit was the Cloudflare plugin. The setting you want to turn off is “HTTPS Protocol Rewriting”. More information about HTTPS Protocol Rewriting here.

You can test the change in your browser by browsing to the AMP version of your page and adding #development=1 to the URL, like so:

http://my.domain.com/post/amp/#development=1

Then inspect the page by right-clicking anywhere on the page and clicking “Inspect”. The inspect console should tell you where in your code the errors are occurring.

Second change:

The inspect console showed me 3 errors:

The attribute ‘type’ in tag ‘script type=application/ld+json’ is set to the invalid value ‘text/javascript’.
The attribute ‘type’ may not appear in tag ‘amphtml engine v0.js script’.
The mandatory tag ‘amphtml engine v0.js script’ is missing or incorrect.

The first of which told me the error was located at this piece of code:

It was Cloudflare again. But this wasn’t caused by the plugin, but by the service itself, namely the Rocket Loader.

To fix it, I logged into Cloudflare.com, and created a rule for /amp/ pages.

My pattern looked like this:

*domain.com/*/amp/*

where “domain.com” is your website domain.

The only setting you need to change from default if Performance is on, is to turn Rocket Loader off.

~~Bonus non-Cloudflare change:~~

If the Google Webmaster Tools says “Required tags missing: amphtml engine v0.js script”, this means you are missing a link tag that references the original non-AMP URL. The browser inspect console will not show an error.

~~I don’t know why the WordPress AMP plugin is missing this, but this is fixed (for now) by editing the AMP plugin file located in /wp-content/plugins/amp/templates/single.php .~~

~~Anywhere between the opening and closing <head> tags, insert this code:~~

~~<link rel=”amphtml” href=”<?php the_permalink(); ?>”>~~

~~and that should take care of it.~~

Update: I don’t know if I missed or misunderstood it, but what I thought was missing is, in fact, supplied by the plug in, but it is

As I mentioned before, I’m still getting some validation errors. Hopefully I will remember to list them here… and not wait for over a year to post again. 🙂

SumoMe Fixes

Posted on February 12, 2014 by Jeff Heck

Update March 23, 2015: This does not work for the current version of SumoMe. But I will keep it up to help with similar situations.

The folks at Appsumo.com have released a free WordPress plugin called SumoMe that is available at http://sumome.com.

You can install SumoMe by either by adding a script to your header (if you are not using WordPress) or by installing their WordPress plugin.

Once you install it and create an account, you have the option of adding two apps:

Twilighter is a slick app that takes the text that is selected on your page and sets up a Twitter tweet using the selected text and creating a short URL back to the page from which it was selected. Your visitor can then make adjustments and click the submit button to tweet it.

The other app is List Builder which opens a modal subscription form that only asks for an email address. You can export the collected addresses as a CSV file.

List Builder caused a problem with this site where the form was showing up behind my header graphic. The problem was the z-index for that DIV element was not high enough. Adding the following code to my style.css file fixed the problem by increasing the z-index value.

.sumome-popup {
     z-index: 11111 !important;
}

Another issue I wanted to fix was the fact that the SumoMe has a control tab that appears in the upper right and visitors can see it. That control tab is of zero use to a visitor, so it is just clutter, yet I will need the tab to change settings. The best solution for now is to make it visible only if an administrator is logged into the site. Please note this code only works if your site is running on WordPress. A hat tip to koningdavid for posting the answer to a similar problem on StackOverflow.com.

Add a style sheet file called visitor.css with the following code:

#sumotest-badge {
     display:none !important;
}

In your theme’s function.php file, add the following:

function visitor_stylesheet()
{
     if (!current_user_can( 'manage_options' )) {

          wp_register_style('visitor_css', get_stylesheet_directory_uri() . '/visitor.css', array(), '1.0', 'all');
          wp_enqueue_style('visitor_css');
     }
}
add_action('wp_enqueue_scripts', 'visitor_stylesheet');

The visitor_stylesheet function checks if the current visitor to the site is an administrator (if the user can “manage_options”, then the user is an administrator). If the user is not an admin, then the visitor.css file is loaded for the user. The CSS code in visitor.css tells the browser to hide the #sumotest-badge DIV element.

Those are my fixes for SumoMe.

Happy cooking!

Managing Database Backups

Posted on January 16, 2014 by Jeff Heck

It is wise to keep backups of your blog’s database, and wiser to keep those backups somewhere other than your blog’s server.

How I keep my backups is not a perfect plan, but it works for me. I keep a month’s worth of my backups in my Google Mail account.

Here’s how:

Install a plugin (like WP-DBManager) that will automatically backs up your database and emails the backup file to your Google Mail account (Gmail.com or Google Apps for Domains) as an attachment. Go ahead and manually have the plugin send a backup to your email account – you need to test it anyway.

Check your email and open the email containing your backup file.

Copy the subject line.

Click the “More” button, then click “Filter messages like these”. The advanced search form will come up with the “From” field already filled out.

Paste the subject line into the Subject field.

Check the “Has attachment” box.

Click “Create filter with this search”

On the next screen, under “When a message arrives that matches this search:”, check the box “Delete it”.

Click “Create Filter” and you are done.

Why delete the backups as they come in? I am not permanently deleting them, just sending them to the Trash folder, and everything in the Trash folder that is older than 30 days is automatically permanently deleted. This saves me from needing to clean out the old backups myself.

One thing to remember is this does not back up the actual files on your site. A copy of the files on my sites is on my computer which is backed up using Crashplan.

WordPress Safety Tips

Posted on January 29, 2013 by Jeff Heck

Some of the sites I managed have been hacked… again.

Here are some changes I’m making to prevent future hack attempts.

1) Install the “Limit Login Attempts” plugin.

Like its name suggests, this wonderful plugin limits the number of times someone can attempt to log in. If they fail, their IP address is blocked for a set time. You can set the number of attempts to allow, how long the block lasts, and if you want to be emailed when someone is blocked. The plugin also keeps a log of IP addresses, so you can add them to your blacklist (if you use one), and logs the username of the attempted log in so you can check with that user if they need assistance.

The main benefit of the “Limit Login Attempts” plugin is if a hacker is using a brute-force method to find your password. Typically, the hacker will run a program that will repeatedly try different passwords until it is able to log in. The limit on login attempts slows the hacker down in his attempt greatly.

2) Never use “admin” as a WordPress username.

It’s temping to use “admin” as the first user since it is the default username WordPress gives you when you set up your blog.

With the “Limit Login Attempts” plugin installed, I found the hacker was repeatedly trying to log in as “admin” using a brute force method, but he was not trying the other accounts. I set up a new administrator user account for myself, logged into the new account, and deleted the “admin” account, being sure to set existing posts with my new account as the author. I think it would also be helpful to make sure your “Display Name” is not the same as your username.

3) Create a good password of 12 characters or more

Use Upper and lowercase letters, numbers and symbols. Get a password manager to keep all your logins straight.

What has not worked:

Google Authenticator Plugin. I had this installed on a blog that was previously hacked, but I did not have “Limit Login Attempts” installed at the time. The hacker still got in using what I presume to be a brute force attack. The Google Authenticator plugin just made it a pain trying to get back in, but I found deleting the plugin via FTP gave me access again.

I think Google Authenticator is still a good plugin when paired with a system the limits the number of login attempts. Even Google does this by using a captcha system.

TL;DR

To keep your WordPress blog safe from brute-force hackers, install Limit Login Attempts, never use “admin” as a username, and use a good password at least 12 characters long using upper and lowercase letters, numbers and symbols.

An error occured while updating a plug-in

Posted on April 21, 2011 by Jeff Heck

I tried to update my plug-ins and one or more of the plug-ins gave me an error that looks like this:
An error occurred while updating <plug-in name>: Could not create directory. <full-real-path-of-folder>.

Then I went the plug-in page and it says those plug-ins have been deactivated because they are not found.

Then I tried to reinstall those plug-ins, but that gave me an error.

Then I tried to upload the plug-ins using an FTP client, but I got a “550 Access denied” error.

I logged into my Godaddy Windows shared hosting account. When I tried to access those folders, I got another “Access denied” error.

To fix it, I went to the parent directory “wp-content/plugins” and reset its permissions. I unchecked “inherit”, then checked “read”, “write” and “Reset all children to inherit” then clicked OK and waited for the operation to complete. I looked in the plugins folder and found the problem folders were no longer there, but I could reinstall them successfully.

I wish I could remember where I heard how to fix this, because I would like to credit where it’s due.

On a another blog I maintain, I thought I could prevent the install error by resetting the folder permissions before updating. Nope, didn’t work. The plugin folder did not have “inherit” checked, but did have “read” and “write” checked. I checked “Reset all children to inherit” and click OK as before. So I tried again, but this time click “inherit” for the “plugins” folder and checked the “Reset all children…” box, and it worked that time.

So it looks like if the “inherit” box is checked, you need to uncheck it and vice-versa. Just as long as read and write permissions are getting set for the child folders.

The same plug-ins that gave error when updating on the first blog gave me an error on this blog. Some plug-ins updated fine. So I don’t know if the problem is with the server, the plug-ins, or a combination of both.

Anyone else having this problem on a Godaddy Windows server?

WPressureCooker.com

Cooking up Wordpress

Category Archives: Plugins