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?

The new WordPress 3.1 Admin Bar

Posted on February 24, 2011 by Jeff Heck

With the release of WordPress 3.1 comes a new admin bar that appears on your site if you are logged in.

If you don’t like it, you can turn it off under your profile settings.

I think I will stick with my current admin bar plugin by Viper007Bond because it has more options.

Hide email addresses with emObA

Posted on February 24, 2011 by Jeff Heck

The spammers are out there, and they are relentless.

You leave one unprotected email address in a post and they will find it.

emOba does a nice job of hiding your email addresses whether you have the email address embedded in a link or displayed as text.

If you are using a plugin like WP Touch to make your site mobile-device friendly, be sure to copy the CSS code from Emoba’s CSS file into the mobile theme’s file or the @s are going to appear huge.

Domain changed!

Posted on October 7, 2010 by Jeff Heck

So I changed the domain to WPressureCooker.com.

I thought I’d share how I did it to show how to do it so you don’t have to worry about folks trying to get to your site through the old domain and getting a 404/”file not found” message.

The first thing I did was some research to find the best way to do this.

Quick disclaimer: This may not be the best way for your site. But this worked for me. Be sure to back up your database and files before proceeding.

I followed the Yoast.com site’s advice and created a robots.txt file, but ended there because I was not moving any files and he was giving instructions for an Apache server where I was using a Windows server hosting plan.

In my Godaddy hosting account, I set the new domain (wpressurecooker.com) to point to the same folder wordpressurecooker.com is pointing to, and waited for the status to go from Pending to Setup.

Logged in my site’s admin and went to the General settings. There I changed the Blog URL and Site URL to the new domain name.

I installed the plugin, Domain-Change by Soz which creates the 301 Redirect for you that automatically redirects folks from your old domain to the new. So if someone comes to your site by a link that goes to a specific article, the page comes up under the new domain. Even my shortened Pretty Links worked.

I deleted the robots.txt file from my site.

Next came the stat tracking. I use Google Analytics. I was hoping that the 301 redirect will take care of most of the problems, but just in case, I made a change to my Google Analytics account and the Google Analytics for WordPress by Joost de Valk settings. There is the possibility I did this wrong, but in Google Analytics for wordpressurecooker.com I set it to track “multiple top level domains”. I noticed the code (that you would paste in if you didn’t use the plugin) changed where _gaq.push([‘_setDomainName’, ‘none’]); so in the plugin settings, I set Domain Tracking (which sets _setDomainName) to “none”.

I also have WordPressurecooker.com registered under Google’s Webmaster Tools. That required me to verify the wpressurecooker.com domain, then for wordpressurecooker.com, I clicked “Change of address” under “Site configuration” I set the New URL for wordpressurecooker.com to wpressurecooker.com. In the settings for wpressurecooker.com I set the sitemap URL.

It took me a lot longer to type this all out than to make the changes, so I think you will find it pretty easy.

So did I miss anything?

FeedWordPress making invalid RSS?

Posted on April 21, 2010 by Jeff Heck

As I mentioned in my last post, I’m using FeedWordpress to syndicate affiliate links. I turned on the option to have the permalink to the affiliated articles to go straight to the affiliate link instead of the page (that may be bad for SEO, but one less click for visitors).

The problem was the RSS feed became invalid because of the affiliate link. So I need to encode the link. So on line 590 of feedwordpress.php, I changed

$uri = get_syndication_permalink();

$uri = esc_attr(get_syndication_permalink());

The esc_attr function is a built in WordPress function that converts certain characters to their HTML encoded equivalents. Such as “&” becomes “&”.

Everything seems to be working fine now.

LinkShare AdMix and SEO Friendly Images plugins

Posted on April 16, 2010 by Jeff Heck

If you are a LinkShare affiliate, there a great plugin called LinkShare AdMix that uses the RSS feeds of retailers you have partnered with to automatically insert posts of each item in the feed. I had to do 2 things to get it to work:

Line 111 of feedwordpress.php, I had to change $fwp_path = ‘feedwordpress’; to $fwp_path = ‘linkshare-admix’; because the code was not finding the install folder correctly. Changing the folder name from “linkshare-admix” to “feedwordpress” may have worked too, but there is already a FeedWordpress plugin (which this plugin is based on) out there and should you need to install both for some reason, you don’t need them butting heads*.
Be sure you copy the included Magpie RSS files into your wp-includes folder to get everything to work right.

I noticed that the images the Linkshare feed was posting were not SEO’d – no alt or title tags.

Enter the SEO Friendly Images plugin which adds alt and title tags for you based on the posts title and keywords. But it didn’t work.

Usually plugin problem lie in an incompatibility with another plugin, so I disabled a plugin one at a time to determine which one was causing the problem.

Guess what? It was the LinkShare AdMix plugin.

I wondered if the original FeedWordpress plugin had the same problem, so I disabled the LinkShare AdMix plugin and installed the FeedWordpress plugin. Same problem. I remember seeing filters were called in the source code, so I searched for “filter” and found a commented paragraph about preserving the feed and not allowing other plugins to change it. The 2 offending lines of code followed, and I promptly commented them out:

//add_filter(‘the_content’, ‘feedwordpress_preserve_syndicated_content’, -10000);

//add_filter(‘the_content’, ‘feedwordpress_restore_syndicated_content’, 10000);

Update: Yes, I totally missed the built-in option to “Expose sydicated posts to formatting filters” under Syndication options > Post & Links > Formatting >Formatting filters. *facepalm* But this only works for the FeedWordpress plugin. LinkShare AdMix plugin does not have this option, so you will need to comment out the 2 lines of code above to get it work with the SEO Friendly Images plugin.

Commenting out that code worked. Just remember you will need to do this again when the Linkshare Admix plugin gets updated.

In the end, I think I will stick with FeedWordpress instead of LinkShare AdMix because I get more fine tune control and easier to add RSS feeds.

*I think installing both LinkShare AdMix and FeedWordpress would not workout because then need different versions of Magpie RSS. Some recoding would be required to get them to play nice.