Inposure

Going back to 1.0 and then back again to 1.1 seems to have solved the problem. Now only front page and subsequent post listings change with new comments, while individual posts or pages stay as they are (and as they should).

I experimented on my local install. APC Object Cache Backend is definitely a culprit.

https://www.ads-software.com/extend/plugins/apc/

(It is needed for MO Cache, which in turn is needed to speed up translation of .mo files)

Super Cache doesn’t do any caching for me as admin. It just gives a 500 error and leaves a gap on the page where the widget were supposed to be.

I’ll give it another shot at a less busy hour, with cleared super-cache and also cleared APC cache (apache restart)… APC can do nasty things like this.

Nope, sorry, no go; still the same error.

Actually it is not Widget Cache, it is something else. Maybe it doesn’t work with MO Cache and APC Object Cache Backend, given that it complains about objects.

No, that will kill your site immediately. You need to add a prefix (other than wp_, something more secure) to a) all tables, b) fields in the options table, c) fields in the usermeta table.

a) is straightforward, but in b) and c) fields don’t necessarily have any prefixes attached to them. How are you supposed to know which ones to change?

When I installed W?rdpress (without frakking camelcase) years ago, there was NO information saying that an empty prefix was ”not supported”, and if it indeed were not supported it shouldn’t even be allowed to proceed with an empty field; that’s BAD programming.

If this later changes, W?rdpress needs to accomodate for this by adding a prefix automatically when upgrading. You can’t just leave your users in the dark because you can’t program properly. This is pure evil.

Well, if it works, why not break it? After all, you get fly-out menus instead of speed and stability…

Ditto, I am also on a mulstisite install, and just regained my site listing in the admin panel after manually changing the code snippet.

However, that is a hack, not a fix; it will be gone by the next update unless WordPress acknowledges that this is a bug and that it has nothing to do with plugins or themes.

Eureka!

Turned out to be a cache problem after all… APC seems to have stored the old domain name in its cache and never updated, probably because the relevant PHP scripts were untouched. Cache should expire after 2 hours, though. Simple restart of apache revealed the problem.

Poking myself in the forehead, telling myself to remember…

@andrea_r: OK, so I guess it still is hidden somewhere, just that I can’t find it; have to look more carefully.

Didn’t know there was a paid version ?? But then it makes more sense and gives me a better clue.

Actually, no. My c.net and d.info have no corresponding c.b.org and d.b.org, since I deleted them. It has been done before.

WP just needs associate domains with IDs, no need for extra subdomains. That is a leftover from old MU, it shouldn’t be that complicated.

No difference. The point is that WP can’t come up with new.b.org at random, it must be picked from the DB. And I can’t find it there.

siteurl = a.com
home = a.com

etc. Can’t find anything in the main blogs options or other tables either.

new.b.org is nowhere to be found, not even in serialized array strings.

Everything works as intended, except for the admin bar and other places where all blogs are listed; it will show new.b.org rather than a.com in those places.

If I follow that link, I will be redirected to my 404 page, since there is no such blog. (And later I have also removed new.b.org from /etc/hosts, and I don’t have a wildcard DNS setting, so the host doesn’t exist.)

It is not a cache issue… just tried logging in from a fresh test browser. Unless there is a hidden files cache that WP uses.

So WP doesn’t seem to resolve existing blog URLs from any obvious settings, and I am completely lost trying to follow the code into any depth.

WordPress MU Domain Mapping 0.5.4.1

Problem with third party themes is that they are too complex and heavy, not maintained through updates, non-free, too simple, not quite right or something else.

Both Twenty Ten and Eleven have all the features most bloggers should ever ask for, and they can be customized with child themes to avoid looking like everyone else’s blog.

But Twenty Eleven has a serious flaw in that the sidebar is not visible on single posts, and there is no template to get around that. You need to do a major hack to both CSS and code to get right on track again, which kinda disables the advantages with the theme.

Dunno about you, but my regular visitors go from comment to comment with the help of recent comments listing in the sidebar. With Twenty Eleven, they have to add the additional step of going to the front page for each comment. This also puts more and unnecessary stress on the server.

Whoever came up with this scheme clearly doesn’t know anything about visiting blogs, but is a pure design freak without regard for function.

Probably adding the following to the very top of index.php should help:

<?php

I have experienced this when deactivating WP Supercache before. It doesn’t check that the WP define is on its own line before erasing.

Unfortunately, many plug-in coders don’t adhere to the WordPress standards. This is true for Quick Cache, which will modify the very first line of index.php and add a define on the same line as the initial php statement, thereby making it plain text for the web server to display (including your database name and password).