Ryan Duff

@dwinden

Speaking of doing proper reading, perhaps you should read the forum welcome page in the codex, specifically this section about things to *not* do. It’s silly to criticize mods when you’re the one not following the rules.

https://codex.www.ads-software.com/Forum_Welcome#The_Bad_Stuff

There is zero advantage to minifying PHP files.

I have removed unused lines in PHP files and my site is running smoother by doing this. Pages are loading a bit quicker but this maybe because I am looking at all the files and going through the process of removing empty lines of code in all my files.

I’d just like to chime in and clarify that the first statement is correct. You will get no performance boost from minifying PHP files.

The reason you minify (and concatenate) CSS and JavaScript files is twofold. These files are downloaded to the browser. Each character in the file is a byte.

By minifying them you eliminate unnecessary bytes and reduce the file size. This allows the browser to download the resource faster and thus render the page quicker.

By concatenating, you’re combining all of your javascript or css files into a single file. This eliminates multiple file requests from the browser. The fewer files that have to get requested to display a page, the quicker it will load.

PHP on the other hand is all compiled and run on the server before the output is sent to the browser. If you want to speed up PHP, using an opcode cache to cache the compiled php code will speed up things. Eliminating whitespace in those files won’t. It just makes them harder to read and edit.

Hope this helps clarify a few misconceptions here.

What happens if you do https://example.com/product-category/term1+term2/ ?

Not sure if that resolves in WooCommerce or not. You may need to register a new rewrite rule if it won’t handle it out of the box.

WordPress does a good job of handling ‘,’ (or) and ‘+’ (and) operators when parsing query strings so that may work.

The theme dropdown gets cached for 1 day to prevent it from having to happen on every page load. I’ll see if I can update it to clear that at least when a theme is installed or deleted.

Not 100% sure but I’ve always had the root line without trailing slash. May be what’s breaking location /

root /path/to/wordpress;

then

location / {
		try_files $uri $uri/ /index.php$is_args$args;
	}

In most servers where I run into the prompt for credentials screen on upgrade, install new plugin, etc, the following line in wp-config.php solves it.

define( 'FS_METHOD', 'direct' );

There are more options available at https://codex.www.ads-software.com/Editing_wp-config.php#WordPress_Upgrade_Constants if needed.

Check inside your uploads directory– remember, you’re not placing file there, but in a sub-folder. Assuming you’re doing this today and you have it set to organize media by date, you’d want to check uploads/2014/02/ and see what it has set.

Because it’s a submenu page you need to use:

add_action('admin_init', 'remove_permalink_menu', 999);
function remove_permalink_menu()
{
    remove_submenu_page( ‘options-general.php’, ‘options-permalink.php’ );
}

I’ve been waffling on using this for the client… but may be able to throw in some time to make it work… is your current dev committed to trunk in the plugin svn repo or do you still have a lot of uncommitted changes?

I know they’re working on backward compat. Waiting things to settle is probably a good idea. Hopefully once we hit RC (very very soon) we’ll have a good idea.

The only reason I asked was because I was considering using it on a project and I saw some of the screenshots. I haven’t looked at how you hooked in to the media thickbox, but I know that has been a touchy area in the past.

Ticket to clean up new user nonsense… https://core.trac.www.ads-software.com/ticket/21910

wp_create_user() is a helper function for wp_insert_user()

Problem with wp_insert_user() is that it will set the default role which is something that wpmu_create_user() actually strips out upon successful user id creation.

Working on a trac ticket regarding this and will cross post link once I’m finished composing.

Generally when I get login redirect loops after migrating it’s because the “siteurl” and “home” entries in the wp_options table don’t match what you’re accessing in the address bar.

Not always the cause but a good first place to start

I can only help as much as you’re willing to troubleshoot. You’ve only repeatedly explained the problem you’re having so I’m pretty much at the end of what I can help with.

The query vars are what changes what next link gets generated. Either something is being lost from them, or something is changing them. This can be IIS or other erroneous code that’s changing the vars as the page is being loaded causing it to return a link back to posts, and not page 2, etc of “pages”

You can say you have almost the same setup on Apache is not the same as testing that *actual* install on Apache. That’s the only way to rule in that it is in fact an IIS issue and not something else.

I guess the simplest way to troubleshoot IIS at this point is to make a backup w/ something like BackupBuddy and import it on an Apache web server and see if it happens.