Steve Blackwood

That WILL allow dots in the blogname, BUT, it’ll also allow the following invalid patterns:

.blogname.domain.com
blog…..name.domain.com
blog.name..domain.com

IOW, it will allow the dot character anywhere, and any number of times. Probably not what you want, since those are invalid URLs. ??

That can get confusing in the midst of a preg_match that returns an error if TRUE — like we need more confusion. What I’d probably do is go ahead and use your modified REGEX in that preg_match test, and then add a second test to your filter, looking for a starting|trailing dot, or a string of more than one dot. And I would probably NOT do that second check with REGEX! <g>

I don’t see a “ServerName mydomain.com” directive in your VirtualHost block. Do you have an old version from when it worked to compare it to?

Can you post the new REGEX? Offhand, sounds like it might allow multiple dots in a row, which wouldn’t be a valid URL…

I checked your query against a WP install with 2500+ posts, and got this:

Showing rows 0 - 11 (12 total, Query took 0.0002 sec)

So, the problem isn’t in the query syntax. Works as expected. I think you need to let WP complete the run (you said you stopped it prematurely above), and see what the actual output is. MySQL doesn’t appear to be the bottleneck, unless you have a problem in your server’s install. The only way to know for sure would be to run it on your own server, against the actual database… if you don’t have that skillset, ask a trusted colleague. Gotta be something in the PHP side of things.

Sorry I couldn’t be more help. ??

That was WITH the SQL_CALC_FOUND_ROWS command, btw, so that wasn’t slowing things down noticeably.

Found one prob…

https://dev.mysql.com/doc/refman/5.0/en/information-functions.html#function_found-rows

The sql_calc_found_rows returns a count of all rows found, as if there were no limit clause. So, it looks thru all rows, regardless of any limit. Remove that and see what happens.

I’ll try to duplicate the query (and bug) later tonight on an old WP db I have access to… but might not work on different data.

Maybe give a trusted compatriot access… Hard to debug MySQL without working with the db itself. <shrug>

Do you have access to PHPMyAdmin? You need to debug MySQL statements on the db itself if you can, and take WP out of the equation. Then you can actually let the query finish, since the returned rows might give a clue to the problem. For instance, I once had a bug in my where clause that caused the same 20 rows to be returned 100 times. Just seeing that told me what the problem was.

I would also recommend culling parts of the query to pinpoint the troublesome part. Take the whole parenthesis out, for example, and whittle down ’til it works as expected.

Yes, that’s the proper set of instructions to follow. Once you’ve made those changes, WordPress will automatically correct the menu links, and everything else — it’s pretty smart that way!

One important thing, be sure to remove that redirect you created via the Network Solutions tool. Otherwise, your site will get into a redirect loop, where the root directory tries to forward to the wpsite directory, then WP tries to send back to the root, and over and over again.

I would take that redirect off first, then follow the tutorial on the Codex, and you should be fine.

Hey Jaeeun,

I think what you’re asking for is usually referred to as “infinite scroll”. The home page of a site will usually load with a few posts, then as the user scrolls to the bottom, another batch of posts is loaded, and so on. This technique is being built into several themes these days, but there are various ways you can add it to an existing theme. If you know how to develop themes, here’s one tutorial I found that walks you through the process step-by-step:

Add Infinite Scroll to a WordPress Theme

Or, you can take the easier route and use a WordPress plugin. Here’s the first one I found:

Infinite-Scroll

FWIW, I haven’t tried either, so user beware. ?? Hope that helps!

Assuming this is what you mean by debug output in in the head:

<--
generated in 0.081 seconds
15980 bytes batcached for 300 seconds
-->

Then it’s working great here.

Mark’s APC Plugin Version 2.0.3
APC Version 3.1.6
PHP Version 5.2.17

Loving it! Fastest my site has ever been. If there’s supposed to be other output in the header, then nope.

1. Nope, I created a new tax for regular posts and pages. No new post types.
2. No, hierarchical only.
3. Nope again. ??

My need is pretty simple… I have a dozen or so authors, each one responsible for a different subject. I would like each user restricted to that subject (the custom tax). However, I don’t want to use the built in Categories taxonomy for this, because they need to be able to share categories.

Thanks… and Roll Tide!

(Another ‘Bama boy)

Is this something that can be added as a Super Admin option, because regular users who sign up on an MU/3.0 and get a blog don’t need to be mucking around with the caching stuff? That should really be a Super Admin thing only, IMO.

For example, you can’t get a WordPress.com blog and expect to configure your own caching/cdn… Automattic does all of that stuff behind the scenes, and it is the default setting for all users. As it should be, since it’s a back-end kinda thing.

Perhaps there could be some core settings that can be added as wp-config variables. The users never see wp-config, but the same file works for every blog, so this would be a perfect place to set those vars without Joe User poking his fingers in the pie. I know one of the WP SMTP plugins uses this method for MU installations…