WordPress URL generation

Were that true there would be lots more support forum threads I think…

I meant, when I look at my source for my page. Lots of http: a few https: here and there.

That’s not a good idea and you’ll a) possibly make your installation insecure or buggy and b) you’ll lose any of your edits when a new release comes out.

I know that. Fix WP and I’ll stop doing it.

It’s an inconvenience to you perhaps but it is absolutely not a security issue here.

Strongly disagree. There are apparently MANY ways URLs get generated in WP and the rate of inconsistency is high which tells me that the way URLs are generated is not well thought out or well designed and this means it is not all that secure either. Secure code is simple and consistent code. I’m seeing neither here. If every single URL were generated incorrectly I might buy it. But the large number of places I had to institute hacks to get the URLs correct tells me that this is a real problem that requires a real rethink.

It’s an old topic and the outcome of it is “Absolute URLs are here to stay”. I believe that that is partly because it works well for the majority and partly because it would be nightmarish to change it.

So the opinion of the WordPress developers is code that works for the majority is better than code the works for all? That is a disturbing attitude. It may well speak to why I’ve had 8 WP sites hacked in the last three weeks. No, I haven’t figured out how they’ve gotten in. But I can see that there is a lot of inconsistency and gratuitous complexity here. Supposing I do the leg work to get url generation fixed? How do I submit that patch in a way that is likely to be accepted?

As to mod_sub, that would be a bandaid to fix a problem that simply shouldn’t exist in the first place. I’d rather generate the correct HTML in the first place. I’m willing to dive in and figure out a better place to patch it, but the fact is that WP is using several inconsistent methods to determine protocol to generate URLs and the fact is that this is work that doesn’t need to be done at all. It makes the site more fragile.

I would buy “not broken” if all of the schemes at the fronts of the urls were the same. They’re not. Hence broken.

I’ve downloaded the source and will submit a patch. I intend to also highlight its inconsistent behavior across the web until the problem is fixed either by a single flag that can be set to specify generation of the correct url scheme in the admin that is actually properly honored by client code or by adopting protocol-relative URLs.

I have read the “justification” for using absolute URLs at http://make.wordpress.org/core/handbook/design-decisions/ and while I’m fine with including the server name in the URLs, I think any design that requires search and replace operations across an entire database is pretty fragile. Furthermore, I notice that the section on SSL and load balancing is blank which to me indicates that they recognize there is a problem, but haven’t thought it through.

So after some more investigation I have found that the core culprit is this function

function is_ssl() {
	if ( isset($_SERVER['HTTPS']) ) {
		if ( 'on' == strtolower($_SERVER['HTTPS']) )
			return true;
		if ( '1' == $_SERVER['HTTPS'] )
			return true;
	} elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
		return true;
	}
	return false;
}

It is wrong because of the proxy. There needs to be a way to override this cleanly. I found that just changing it to return true solves my issues. Why the database content links get figured one way and the supporting script and styles get figured another is a mystery to me.

I appreciate the support from alamart.

I think the reason WP is the way it is is because it is generally installed in place, edited in place, and never moved. Basically it is designed for amateurs who edit and develop things live on their one copy.

Professional organizations generally have multiple servers for development, staging, and production and thus pages may be accessed via different server names, behind proxies, and etc….. Code moves form dev to staging for approval and ultimately is placed before the public on production.

Dumping the protocol would be a great step in the right direction though – ultimate protocol is not always known to the server if it is part of a distributed deployment – for instance behind a load balancer that is handling the https side.