David Cameron Law

Not used this plugin yet, was thinking about using it on a domain mapped setup if I ever get it working ?? and downloaded it today (still got the issue code).

Anyway, looks like it’s easy to disable, this is what I’ll do before using it:

In file
yd-wpmu-sitewide-options.php

Change line 689 to

#add_action(‘wp_footer’, ‘yd_wpmuso_linkware’);

Will prob delete the yd_wpmuso_linkware function as it won’t be called. That is a bizzare way to disable a link, comment it out. That is so 10+ year old SEO technique to believe a HTML commented out link would still pass SEO value! They should have gone for noscript tags if they wanted it hidden, but count SEO wise. SEO amateurs ??

That should stop the footer link and for those with the issue of having to edit each site, no longer an issue.

You could also remove the link from the admin as well, line 662

#add_filter( ‘plugin_row_meta’, ‘yd_wpmuso_links’ , 10, 2 );

This plugin should be removed from the repository until the issue is fixed, someone who has used it should email [email protected] and report the problem. Since I’ve not used the plugin wouldn’t be right for me to report it.

David

Nice code fix CodingFabian, I have a plugin derived from CRP and have been trying to figure out why it was interacting with a widget and generating over 100 extra database queries.

Basically CRP is loading even for posts that are not within the main loop which meant if a widget or other plugin pulled say 5 posts the CRP code would try to find related posts for the 5 posts!! If you had the plugin set to show 5 related, it’s finding 30 which it is showing 5.

The code above fixed it removing over 100 database queries from single posts.

There’s a similar issue with the code running on archive pages, in this case it was worse because it would find 5 posts for the 10 archived posts on an archive page, so 55 posts found with none shown since CRP doesn’t output anything on archives. I fixed it about a year ago in the plugin I use, it was resulting in 200+ extra database queries on archives.

CRP is a great plugin base, I’ve added Timbthumb support, random thumbnail support, linked it in with a derivative of the All In One SEO Plugin pack so the anchor text and alt text can be changed. My version is hosted at https://www.stallion-theme.com/wordpress-seo-plugins and will be updated soon (need to test it on a theme other than Stallion – SEO theme I develop). Go to the Related Articles at the bottom of the page and refresh the page and see the thumbnails change, pretty cool.

David

Looked through a dozen or so pages before finding this one, the other solutions either didn’t work or basically turned the function off which meant when the plugin was disabled the notice it was disabled was gone.

Thanks Wes ??

David

Your problem will be believing adding meta descriptions and meta keywords has an SEO ranking value.

Meta keywords has NO Google ranking value, waste of time using them Google completely ignores them.

Meta description has NO Google ranking value, but MIGHT be used by Google as your pages description for a SERP that MIGHT if the searcher finds your custom description compelling (ad like) result in a higher click through rate, but it won’t take a page from say 5th listing for a SERP to 4th listing (no ranking value).

You’ve also made the mistake in using the default settings for the plugin for your titles:

Post title | Name of site
Photographic Courses | liquidmocean

This is no better than what most themes generate out the box:

Name of site | Post title
liquidmocean | Photographic Courses

Best SEO title element is ussually:

Post title
Photographic Courses

Unless your site has a recognisable brand like Amazon.

David

Had this issue on a localhost development server: Windows with Wampserver installed.

The problem was fixed by using your development version.

Not tried the plugin on a live site.

David

No problem.

Not particularly good with optimising database queries, but you might be able to use a better implementation and reduce the number of database queries by not checking the entries with post_type as nav_menu_item and revision.

When I went searching for the cause of the issue I was surprised to find how WordPress generates the nav menu items, it’s a copy of the entire post entry with a different post title! This is bound to generate problems with other plugins that assume everything in that table is a post.

Feature suggestion ?? Just started testing with your plugin, upgrading from the very old (and very good) related post plugin from Alexander Malov & Mike Lu (which needed a similar fix). In my current setups I don’t use lists for the output, put them in a paragraph with a header surrounding the link.

h4 link to post /h4 P excerpt…. /p

See the link I added to the first post above for example.

Although you can surround the entire link with your plugin you can’t style the anchor text of the link with a header. I realise I could add styling via CSS, but I’m using the header code for SEO reasons: if a related posts plugin grabs relevant posts, the anchor text of those posts are likely going to include relevant keywords and by giving them a low level header (h4, h5, possibly h3 if you don’t add h3 to your posts) you potentially add optimisation for long tail related SERPs (I’ve been doing SEO way too long :-))

David

Fixed it,

Here’s the changes I made

if ((is_int($post->ID))&&($stuff != '')) {
$sql = "SELECT DISTINCT ID,post_title,post_date,post_content,post_type,"
#        $sql = "SELECT DISTINCT ID,post_title,post_date,post_content,"
        . "MATCH(post_title,post_content) AGAINST ('".$stuff."') AS score "
        . "FROM ".$wpdb->posts." WHERE "
        . "MATCH (post_title,post_content) AGAINST ('".$stuff."') "
        . "AND post_date <= '".$now."' "
        . "AND post_status = 'publish' "
. "AND post_type != 'nav_menu_item' "
. "AND post_type != 'revision' "
        . "AND id != ".$post->ID." ";
        if ($crp_settings['exclude_pages']) $sql .= "AND post_type = 'post' ";
        $sql .= "ORDER BY score DESC ";

Changes to contextual-related-posts.php

Edit one line and add two new lines to check a post isn’t post_type nav_menu_item, also added revison as well as they have a different ID and assume users who use the default dynamic URLs will get links to the wrong dynamic URL.

David

I’m rewriting a themes code (theme runs on thousands of sites) for a new release and have it working perfectly in WordPress 3.0.4 and below, wise to test on the beta release and hit a snag.

The padding was breaking my themes layout, wasn’t able to get it to work with WordPress 3.1 and earlier version of WordPress. One div was thrown off.

I tested Esmi’s code with my theme and it looks like it resolves the issue.

I have a div positioned with this CSS

.navbar {
width: 990px;
position: absolute;
top: 115px;
}

this is not unusual theme code.

With the current WordPress 3.1 beta code it’s obviously not taking the 28px padding into account, so when the admin bar is present it’s 28px to high. With Esmi’s CSS code (as a replacement for the Admin bars CSS) it’s where it should be.

I didn’t want to force theme users to turn the admin menu off by default.

I’ve fixed the issue by adding a wrapper div to the whole theme and giving it position:relative; which means the absolute element that was being positioned absolute to the body is now positioned absolute to the wrapper div which is padded down in WordPress 3.1 and not in WordPress 3.0 and below. Really shouldn’t have to add this fix when a simple bit of CSS on the admin bar would have avoided it for my theme and presumably lots like it.

David

Turns out it’s not the id=”” part per se that’s being deleted, but everything after the class and title attributes.

When I’ve tried code like

<span class="classname" title="titlename" rel="uniquenumber">

<span class="classname" title="titlename" rel="uniquenumber" id="uniquenumber2">

<span class="classname" title="titlename" id="uniquenumber"  rel="uniquenumber">

They all end up as:

<span class="classname" title="titlename">

David

ROFLOL, turns out I’d already got it working, but have found an interesting feature of WordPress that if you exclude all top parent level pages (which I had in my test) you get the second level child pages shown!

Would that be a WordPress bug?

Anyway, both of the above two solutions worked, I’d tried the first one with the test of blocking all top level pages, but didn’t realise the links had changed from the top level to the second level.

Thanks

David

The above is a big SEO issue with the vast majority of WordPress themes.

The majority use a H1 header for the name of the blog and H2 for the title of the article!

It should be H1 header for the title only for the home page and monthly type archive pages, rest ideally wouldn’t have a header at all (style them like a header using CSS) and H1 used for the name of the article and name of Categories and Tags.

H2 headers are generally used on the sidebar as well, another waste of SEO relevance.

I had a quick look at your zip file and it’s a good start, if you wanted to take it to the next level you’ll want to include if statements for categories, tags and even search pages (I have loads of sites with search results indexed in google). Take a look at https://www.google-adsense-templates.co.uk/ to see it all in action (no wasted headers), view a variety of pages and view source to see. I’ve worked years on SEOing WordPress themes and I make the best optimized WordPress themes available today by far.

BTW it’s not WordPress core at fault here, it’s the themes, though it could be argued the default themes shipped with WordPress could incorporate some basic SEO into them.

David

Hi Esmi,

Since this is a second copy of single.php (I named it single2.php) and all it does is create pages like https://www.45-year-old-millionaire.co.uk/claiming-working-tax-credit-instead-of-job-seekers-allowance-income-support.html/comment-page-1?cid=7006 I don’t need too many plugins to work with those pages.

Remember this is just about getting the plugin SEO Super Comments to work correctly which generates individual pages from comments.

On the example page above you’ll note the Tweetme link (from a plugin) isn’t working correctly, doesn’t work on these pages with <?php wp_head(); ?> included either (need to find a fix to block that plugin on those pages). Had a similar problem on another site with a poll plugin that called javascript via the header, had to add it manually so a poll widget would work on these pages.

You expect a few issues like these when you use plugins like the SEO Super Comments that’s doing something WordPress is not designed for (comments aren’t supposed to have their own pages).

I did realise later I could use something like:

remove_action (‘wp_head’, ‘rel_canonical’);

Added to the functions.php file to block this filter completely and rely on the code I used to use to generate the canonical links. Currently testing with this option ??

David

Solved the problem, pretty easy as well.

Deleted

<?php wp_head(); ?>

From the extra single.php template page.

David

Thanks ryanve, just started using Tweetmeme (today) and I had the exact same problem under WordPress 2.8.6 and WordPress 2.9 (upgraded to see if that was the issue), works on the home page, but no where else.

Added the above code to single.php page and now it works.

The theme I’m using at https://www.general-election-2010.co.uk/ was created by me (I sell it) and understand Tweetmeme is one of the more popular Twiiter plugins and would like to have it work out the box with my theme. Anyone know why Tweetmeme doesn’t always work on single post and pages, but fine on archive pages?

On my theme the code in the archive template files is similar to the single.php and pages.php templates, about the biggest difference is I use the content excerpt function on the archive pages, but I can’t see that being the issue.

Before trying Tweetmeme I installed a plugin for https://topsy.com/ and that worked first time with my theme.

David

I eventually ruled out WordPress as the cause of the hacking of my sites.

Although I couldn’t 100% confirm this, the most likely cause was a vulnerability in an old version of Adobe reader browser plugin allowed a hacker access to my work PC, they used that vulnerability to gain access to my FTP username/password list stored in Filezilla which doesn’t secure the stored passwords! Big mistake saving password in an unsecure way in Filezilla, the programmers have really dropped the ball on this issue.

Scanned my PC multiple times with a variety of products and nothing unussual showed up, so it might not be the above, but it is a known issue and the only one I could find that makes sense.

After cleaning out the changed files and changing FTP passwords I’ve had no other problems on the server. There was no evidence of root access, was only FTP access that was logged.

Was a pain in the butt deleting and reinstalling 129 domains and sub-domains to be sure there was no infected files under FTP access!

David