LoneWolfMuskoka

Thanks @wfphil!

My ISP (Xplornet) is using the Hughes satellite modem, so it seems that this is exactly what I’m seeing. The thread you suggested is spot on! It is good to know that this is not malicious – or my fault!

Thank you so much for digging into this for me. I’m not sure why that thread never came up in my searches as it hit so many of the keywords I was looking for. Perhaps it was buried a few pages in.

It appears that the randomness I was seeing is because sites using https protocol don’t get the injected code. A quick test seems to confirm this.

I guess it’s time to look into getting certificates for all my sites.

One problem that the OP brought up was that they were no longer given the option to select different templates when creating a page. That was not a change in WordPress. It is the fact that the theme no longer had multiple templates to chose from, so the choice is not presented.

Thanks edwinkwan!

It seems that there must have been something cached somewhere in my browser that caused this to happen. After restarting the browser I’m getting the the page without the redirect.

FF must have cached the 301 version which is why the main author page was still redirecting but the new author page wasn’t.

While I think you are probably right, I think it would be possible to have the flexibility for those that want to go beyond the standard loop.

After looking at the documentation for get_template_part() and the example they use for the loop I think it wouldn’t be much of a stretch to expand that. Have the ‘name’ argument default to the name of the current template piece rather than nothing. The same thing could be applied to the ‘name’ arg for get_header(), et. al.

Then add a get_loop() (which would be as simple as calling get_template_part(‘loop’, $arg)) and get_post() (probably a name conflict there so a different naming convention might be needed).

Retrofitting an existing theme would be relatively easy as you could just create a couple new files by pulling out the loop(s) from index.php, etc.

Those who need to go outside of a typical main loop would still be free to do their own thing, but plugins based on a standardized loop wouldn’t work with them. They could still make use of get_loop() when it suits their needs.

I’ve been trying to work on a plugin that adds an extra loop (e.g. “Featured Posts”) to any theme on the home page, so having this type of standardization would make it easy to adopt the styling of the theme for the loop by simply calling get_loop().

If someone wanted to add a single post somewhere, the get_post() call would be valuable.

Anyway, thanks esmi and Ipstenu for your comments. It feels good to have some feedback as I think this through. While I agree that this is not likely to happen, I guy can dream can’t he? 8=)

Thanks esmi. It does seem that they are heading in that direction. This would make what I’m suggesting possible for a given theme developer, but it does lack the standardization I’m hoping for.

It would be nice to see every theme use a separate file for the loop and another for each individual post within the loop. The naming convention should be standardized so that a plugin could work with it regardless of which theme was running.

It’s probably not possible for this to happen, but it would be nice.

What I’m envisioning (and it is at a basic level at this point) is an extension of the template hierarchy.

For example, there could be a loop.php and get_loop() function would call it. There could even be overrides like archive-loop.php which is called when get_loop() is called within archive*.php files, etc.

Then there would be loop-post.php which would be called inside the loop with get_loop_post().

You could expand get_header() to load related headers using the same hierarchy.

As you mention, it would be a major change and might break a lot of themes, but it would make life easier especially when building child themes and plugins that work with themes.

I’m getting this message and the link to “Go fix it” leads to the Writing page. There is no “Update Services” on that page.

I am using FD Feedburner plugin to redirect my feeds.

I did some reading on sitemaps at sitemaps.org and it seems that putting them in the blogs.dir subdirectory as I suggested wouldn’t work as a sitemap will only have authority from the directory that it is located in and its subdirectories.

We can use different names for the sitemaps, but I’m not sure how they get associated with the appropriate url. Is there something in robots.txt that needs to get set for this to work? Or is it in the WP url mapping that this takes place? Should the file name in the URL match the actual filename or does that matter?

I’m testing this on a multi site configuration as well, but I’m using subdomains rather than subdirectories. I’m not sure of all the technical details, but I do know that they all share the same directory on the server. When I try to set up a sitemap for one of the child sites it is using the same local path as the parent (and presumably all the others) even though the URL is different.

A couple things to consider:

Does changing the name from sitemap.xml to sitemap2.xml cause any issues on Google, Yahoo or Bing?

Files specific to a domain (i.e. media) are in wp-content/blogs.dir/N (where N is the number corresponding to the site id). Could the sitemaps be put there?

I’ve been using XML Sitemap Feed which generates the sitemap when a robot requests it rather than storing the file. Is this a possible solution to the problem?

I haven’t had enough time to fully test this, but I do like the options that this plugin has for the sitemap. It is more like the Google XML Sitemaps plugin (which I found didn’t work with multi-site installs when I first started out — not sure if it does now).

Anyway, that is my 2 cents so far.

I’ve run across XML Sitemap Feed which works well with 3.0 in multi site mode. It doesn’t have the customization features of Google XML Sitemaps (but I never used them anyway) nor does it ping the search engines. But they claim that WP will do that for you anyway through ping-o-matic, so there really is no need.

That makes sense — the db would be pretty stable except for major releases.

You should find a place to install at least 2.9.2 and test all of your plugins in that environment. That way you will know what issues you’re facing and can deal with them before you upgrade the live site.

Then, once you’re done with that you can upgrade the test site to 3.0 and see how that goes before you do the live site.

I’ve set up a WAMP setup on my own PC that allows me to do some basic testing, but you’re best bet is to install WP in the same hosting environment that your production site is on. You might be able to setup a test subdomain and install WP in there.

I’m running RC2 as well and I don’t have any trouble with this (although I usually access the sites through Super Admin->Sites and then click Backend).

I’m using subdomains rather than subdirectories. Perhaps that may make a difference.

I don’t see this behaviour on 2.9.2. When I ask it to update it does all the steps, start to finish. I’m not sure how that works in 3.0 in single site mode since I haven’t tested that yet. I need multi site for a project I’m working on so that is my focus right now.

What I see when I update the network is a 2 step process rather than 1 step. Still, this is much better than having to run updates on each site individually!