WordPress › Support » WordPress's .htaccess file is suboptimal

WordPress's .htaccess file is suboptimal (35 posts)

cbj4074
Member
Posted 1 year ago #
The .htaccess file that WordPress generates during installation is suboptimal.

The primary issue is that, "out-of-the-box", the .htaccess file functions properly only when the location of the WordPress installation does not change.

In a collaborative, version-controlled environment, it is unreasonable to expect that every developer places every WordPress project in his Web-server's document root. However, the .htaccess file at the root of the installation seems to be generated with this expectation.

I hardly ever use WordPress, so I can't speak to the evolution of this issue, but I seem to recall WordPress including the .htaccess file in the actual source package at some point in the past (as opposed to the file being generated dynamically during installation). If my recollection is correct, perhaps the fact that the file is generated dynamically now is in an effort to address the issue I've outlined herein.

The following issues are at the core of why clean-URLs are not accessible when the WordPress installation is not at the Web-server's document root:

a.) the leading / before index.php in the last rule (RewriteRule . /index.php [L]); and

b.) the RewriteBase / directive

Again, I don't know enough about WordPress to know whether the proposed adjustments will "break" other functionality, but it seems that two simple adjustments would alleviate this problem entirely.
```
# BEGIN WordPress

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
</IfModule>

# END WordPress
```
With these two changes, I am able to move the WordPress installation to any subdirectory of the Web-server's document root and clean URLs continue to function as expected.

As a related corollary, the above changes do not address the fact that WordPress stores core configuration directives in the database, so the developer will still need to adjust the 'siteurl' and 'home' values in the wp_options database table whenever the installation is moved.

P.S. This forum software is inserting HTML markup into my post (specifically, between the code tags) whenever I edit the post.
Jan Dembowski
Volunteer Mod. & Brute Squad
Posted 1 year ago #

The primary issue is that, "out-of-the-box", the .htaccess file functions properly only when the location of the WordPress installation does not change.

...

a.) the leading / before index.php in the last rule (RewriteRule . /index.php [L]); and

b.) the RewriteBase / directive

Just for my own curiosity and nothing else, aside from any perceived inelegance, is there a tangible penalty for doing it the default way which is generated whenever you save your permalink settings?

I'm not suggesting you're incorrect or that you shouldn't modify your .htaccess file this way, I just want to know if there is any harm in the default method. ;)
cbj4074
Member
Posted 1 year ago #

Hi, Jan, thank you for the prompt and courteous reply. Rest assured that I am not "complaining"; quite the opposite. I hope to make WordPress a better platform and to alleviate some of the issues that developers (I know; not WordPress's primary target audience, historically) face while working with version-controlled code and local copies of the WordPress installation.

Thanks for clarifying the important point that the .htaccess file is generated whenever the permalink settings are saved, and not during installation. This is a pleasant surprise.

That said, it is not possible even to log into WordPress, no less access the Permalink Settings, when the 'sitehome' and/or 'home' values, as defined on the wp_options table, are not accurate. This is a separate but related issue.

In other words, whenever we "publish" a WordPress installation (that is, perform a "build" on our development server and copy the files into a staging environment and eventually production), we can't log into WordPress at all. We have to go into the database and change the aforementioned option values manually before even being able to log-in.

So, to answer your question, no, there is no harm in letting WordPress generate the .htaccess file whenever the Permalink Settings are modified, but the values that are written to .htaccess appear to come directly from 'siteurl' and/or 'home', so unless those values are accurate, the .htaccess file will not be effective.
Ipstenu (Mika Epstein)
Half-Elf Support Rogue & Mod
Posted 1 year ago #

The following issues are at the core of why clean-URLs are not accessible when the WordPress installation is not at the Web-server's document root:

a.) the leading / before index.php in the last rule (RewriteRule . /index.php [L]); and

b.) the RewriteBase / directive

You can get clean URLs with WP in non-root. I think I'm missing why you think this is a problem.

When WP isn't in root, and you don't want to run it 'from' root, like example.com/wp/, you just put the .htaccess in the /wp/ folder. That lets you have other apps on the server.

If you want it to be in root, you can change the rewrite base to /wp/ and it works fine.

Where are you seeing this being a problem?
cbj4074
Member
Posted 1 year ago #
When WP isn't in root, and you don't want to run it 'from' root, like example.com/wp/, you just put the .htaccess in the /wp/ folder.

This doesn't work (unless the Permalinks Settings are updated to be accurate, in which the .htaccess file is updated accordingly). It works for the homepage, but clean-URL links to other pages yield 404 responses.

I have a WP installation at http://localhost/project (the fully-qualified path to WP's index file is http://localhost/project/index.php). The WP files are stored in a "real" location on the filesystem, and relative to Apache's document root, the path is /project (again, the index file is located at /project/index.php). So, this is precisely the setup that you describe, yet only the homepage is accessible.

If you want it to be in root, you can change the rewrite base to /wp/ and it works fine.

Are you addressing configurations in which WP is installed in the Web-server's document root, but should be accessible at a different URL, e.g., /wp/? Or configurations in which WP is not installed in the Web-server's document root, but should be accessible at the root URL (e.g., http://localhost/)?

In any case, the impetus behind my initial post was that I would like for WP installations to be "portable". That is, I would like for a given WP installation to function identically whether it is installed at the Web-server's document root or not, and whether the URL at which the WP installation is accessed is / or not. Further, I would like not to have to manipulate the database manually any time the FQDN for the WP site changes.

My gripe with having to manipulate the database manually has more to do with using WP in a collaborative development environment than anything else. In my organization, the WP database tables are version-controlled, so that each developer is working with the same data. The fact that WP stores critical URL-related data in the database means that each developer has to change the siteurl and home option values every time he updates his local working copy. (I realize that these values can be overwritten using WP's update_option() function; more on that shortly.)

I understand that my "ideal implementation" is not possible without some kind of a configuration file. WP already has wp-config.php, which seems like a far more appropriate location in which to store core/critical configuration directives (the WP installation's fully-qualified URL falls into this category) than the database.

In other words, I would prefer that WP store the siteurl and home values in wp-config.php, as opposed to the database. If this were the case, our development woes would be solved, as wp-config.php is added to each developer's "ignore list" within his version-control client.

To summarize, it seems that WP would be far more portable and better suited to collaborative development environments if:

1.) The proposed changes are made to .htaccess (provided that no security risks are introduced as a result); this would also eliminate the need to modify this file whenever the Permalinks Settings are changed.

2.) The siteurl and home are moved into wp-config.php. Alternatively, the WP installation documentation is modified to include examples of how to overwrite the values in the database using inline definitions, e.g.:
```
update_option('siteurl', http://localhost/project);
update_option('home', http://localhost/project);
```
The latter option is less desirable, however, due to the associated overhead (writing to the DB every page-request). A possible improvement would be to wrap the above snippet in conditional logic such that the update_option() calls are not executed when the values in the DB already match those specified inline.
Ipstenu (Mika Epstein)
Half-Elf Support Rogue & Mod
Posted 1 year ago #

This doesn't work (unless the Permalinks Settings are updated to be accurate, in which the .htaccess file is updated accordingly). It works for the homepage, but clean-URL links to other pages yield 404 responses.

Huh?

If I install at http://example.com/wp/ all my URLs work just fine, no 404s.

Ditto if I install it in http://example.com/wp/ but use http://example.com/ as my front facing URL. All my posts will be http://example.com/2011/postname and so on.

I have a WP installation at http://localhost/project (the fully-qualified path to WP's index file is http://localhost/project/index.php). The WP files are stored in a "real" location on the filesystem, and relative to Apache's document root, the path is /project (again, the index file is located at /project/index.php). So, this is precisely the setup that you describe, yet only the homepage is accessible.

If that's the case, you screwed something up. I have a WP install also at localhost/tester, and it works just fine. All my pretty permalinks work perfectly and they always have.

Also this statement is 100% incorrect:

this would also eliminate the need to modify this file whenever the Permalinks Settings are changed.

You never need to update the .htaccess when you change permalinks UNLESS you move to a new location. Swear to god. I don't keep my .htaccess writable, and I often change my permalinks six ways from sunday while testing. Once I set it, .htaccess never changes. Otherwise debugging the multisite masses would be a nightmare! Yow!

I would like for a given WP installation to function identically whether it is installed at the Web-server's document root or not, and whether the URL at which the WP installation is accessed is / or not.

That's the thing, it DOES exactly that. Obviously the URLs are different, but that's really how it works.

Further, I would like not to have to manipulate the database manually any time the FQDN for the WP site changes

That's something else entirely and highly unlikely. Look at how WordPress stores links and images. They're all using the full path. http://example.com/2012/postname

That's not going to change.
Andrea Rennick
Customer Care at Copyblogger Media and Studiopress
Posted 1 year ago #

In other words, I would prefer that WP store the siteurl and home values in wp-config.php, as opposed to the database.

See this:
http://codex.wordpress.org/Editing_wp-config.php#WordPress_address_.28URL.29
John P. Bloch
Member
Posted 1 year ago #

In addition to what everybody else here is saying, don't track your .htaccess file in version control. Those overrides are meant to be directory specific for that machine's exact setup. For example, I don't want the caching rules from W3TC coming down into my dev and test environments.

Also, learn to write a virtual host entry and use some more descriptive hostnames. You'll save yourself a world of pain if you're using similar names for production and dev (e.g. example.com and example.dev).
cbj4074
Member
Posted 1 year ago #

If I install at http://example.com/wp/ all my URLs work just fine, no 404s.

Ditto if I install it in http://example.com/wp/ but use http://example.com/ as my front facing URL. All my posts will be http://example.com/2011/postname and so on.

Right, you are installing WP to these locations. You are not installing it to another location and then attempting to get WP to function again when you move the installation to a completely different server that has a completely different FQDN and a different URL to the WP installation.

If that's the case, you screwed something up. I have a WP install also at localhost/tester, and it works just fine. All my pretty permalinks work perfectly and they always have.

Again, you are installing WP to a specific location, so the values in the wp_options database table are accurate, and the values in your .htaccess file are also accurate. Of course everything "just works". I am talking about moving existing WP installations here.

Also this statement is 100% incorrect:

this would also eliminate the need to modify this file whenever the Permalinks Settings are changed.

You misunderstood my statement. I am not talking about modifying the .htaccess file manually after changing Permalinks Settings. I am saying that WP's internal logic would not have to modify the .htaccess file when Permalinks Settings are changed, as it does presently. Trust me, WP attempts to modify .htaccess any time you click "Save" on the Permalinks Settings page (even if nothing is changed, if I recall). Jan stated this in his post above, I tested it, and he is correct.

That's the thing, it DOES exactly that. Obviously the URLs are different, but that's really how it works.

Again, you are fundamentally misunderstanding the entire premise of this thread. I am not installing WP to a specific location and wondering why it doesn't work. I am moving WP installations around and annoyed with the manual labor that is involved each time.

That's something else entirely and highly unlikely. Look at how WordPress stores links and images. They're all using the full path. http://example.com/2012/postname

That's not going to change.

How is that URL not going to change if I migrate the WP installation from example.com to different-example.com? Of course all of the URLs are going to be different (and therefore the values in the DB need adjusting).

Andrea_r, thank link looks to address my concerns, in part if not in full. I will read through the information, digest it, and post back on Monday if I have any questions. Thank you.

John P. Bloch, by making the modifications I have described, the same .htaccess file works just fine for everyone on our development team who is working locally, despite different hostnames and WP paths, which is largely the point of my post.

For example, I don't want the caching rules from W3TC coming down into my dev and test environments.

Right, which is exactly why we don't store those settings in a .htaccess file; we store them in Apache's virtual-host configuration file for the virtual-host in question. There are plenty of reasons for this approach, not least of which is performance.

Your statements seem somewhat contradictory; you suggest not keeping WP's .htacess file in version-control, but at the same time suggest learning how to write a vhost entry (something with which I am perfectly familiar, by the way).
Jan Dembowski
Volunteer Mod. & Brute Squad
Posted 1 year ago #

You are not installing it to another location and then attempting to get WP to function again when you move the installation to a completely different server that has a completely different FQDN and a different URL to the WP installation.

...

How is that URL not going to change if I migrate the WP installation from example.com to different-example.com?

...

Of course all of the URLs are going to be different (and therefore the values in the DB need adjusting).

Sorry, but the whole premise of your discussion is based upon Doing It All Wrong™.

WordPress is not an application that can be moved like that. Never has been. You can't just pick up and move it and expect everything to work without massaging the database. Which even with or without your solution, you admit needs doing.

If you need to touch the database then do it (using one of) the right way as documented.

If you are developing a site and you want to move it to another server lock, stock, and barrel then it's not difficult to do.

http://codex.wordpress.org/Moving_WordPress#When_Your_Domain_Name_or_URLs_Change

Which really does benefit from using this script.

http://interconnectit.com/124/search-and-replace-for-wordpress-databases/

It also requires that you have an understanding of permalinks, how URLs and references are stored in the database, options etc. and it works for both standalone WordPress as well as multisite.

works just fine for everyone on our development team who is working locally, despite different hostnames and WP paths, which is largely the point of my post.

If you are doing this and it works for you and your team, kudos.

But where do you address the links embedded in the posts, the media library, serialized settings, etc? That's not something that an updated .htaccess will or can address.
Paul
Member
Posted 1 year ago #

There's a handy little plugin called MigrateDB
http://wordpress.org/extend/plugins/wp-migrate-db/
Just enter the new URLs and path to root and migrate the database!
cbj4074
Member
Posted 1 year ago #

Sorry, but the whole premise of your discussion is based upon Doing It All Wrong™.

WordPress is not an application that can be moved like that. Never has been. You can't just pick up and move it and expect everything to work without massaging the database. Which even with or without your solution, you admit needs doing.

Massaging the database directly is not necessary when the update_option() "hack" is used.

If WP is not an application that can be moved like that, a) it should be, and b) I will not recommend it to clients. Why should WordPress be exempt from basic application design considerations, among the foremost of which is portability?

The first paragraph in the article you cited makes me shake my head:

The files and database can be moved, however references to the old domain name or location will remain in the database, and that can cause issues with links or theme display.

The fact that WP stores fully-qualified URLs anywhere in the database makes me cringe. I am curious to hear the rationale for this and in my humble opinion this was a poor design decision. Maybe I am just an ignorant boob with no knowledge of WP's inner-workings and therefore entirely unqualified to offer my expertise.

Now, before everybody pig-piles on the "hater", and defends every poor design decision blindly and without due discourse, consider the fact that there are plenty of other CMSs that do not store fully-qualified URLs in the database.

A more sensible approach is to use Web-server and filesystem path constants to define critical paths, and all paths on the filesystem and in the database are defined relative to those. The constants' values do not affect so-called "clean-URLs".

The Web-server constants define a protocol, a domain name, a port, and a base-path, and those four strings are sufficient to compose any URL necessary. When the domain or installation path changes, those are the only values that need adjustment. There's no need to perform selective string replacements on an entire database. There are a number of ways to ensure that the URLs are composed accurately and in accordance with the defined constants when they are output.

Look, I'm not here to argue. I was under the impression that this is a request and feedback forum. I'm given you mine. Take it or leave it.

Thanks to those who provided alternatives and additional work-arounds.
Jan Dembowski
Volunteer Mod. & Brute Squad
Posted 1 year ago #

Now, before everybody pig-piles on the "hater"

Nope, no worries, it's all good. You are definitely not a "hater". ;)

Look, I'm not here to argue. I was under the impression that this is a request and feedback forum. I'm given you mine. Take it or leave it.

You're in the right place and it's feedback. Like I said, it's all good.
fonglh
Member
Posted 1 year ago #

There's a comment by Otto on why WordPress uses absolute URLs. It's not in the main post content, but down in the comments as a reply to someone who asked.

http://ottopress.com/2011/howto-html5-video-that-works-almost-everywhere/
Ipstenu (Mika Epstein)
Half-Elf Support Rogue & Mod
Posted 1 year ago #

If you really want to know, read this thread:

http://lists.automattic.com/pipermail/wp-hackers/2011-October/thread.html#41155

It's long, it's detailed, and that's everything you need to know about why it's done this way.

If WP is not an application that can be moved like that, a) it should be, and b) I will not recommend it to clients. Why should WordPress be exempt from basic application design considerations, among the foremost of which is portability?

a) No.

b) That's your call. No one's going to stop you, though it'd be nice if you'd read the above link first and see that the pros and cons have been fought over a hundred times before :) There is a reason.
cbj4074
Member
Posted 1 year ago #

Thanks, Jan; I appreciate your willingness to acknowledge that criticism is not off-limits.

I read every single word of the thread you cited, Ipstenu.

For those who can't be troubled, Marcus Pope has a long, drawn-out debate on this very subject with Otto (presumably some self-professed WP guru).

Marcus basically embarrasses Otto at every turn and reinforces everything that I've stated in this thread thus far. Rob Lusby jumps-in with poignant observations from time to time in support of Marcus's position.

Having read every single post, it is fair to say that Marcus and Rob trampled Otto in a civil debate, and guess which position they took? They were in favor of relative URLs.

Otto really makes his position clear with this remark:

Yes, okay, you move sites around a lot. I get it. That's great and
maybe your ideas help you. Fine.

But most people *don't* do that. Most people write content in order to
have that content read by other people. And your ideas make that a)
harder and b) broken. That's what I'm trying to get across to you.
Your viewpoint is your own, and by far not the correct viewpoint for
the majority of people.

That's what I want you to see here. You think that relative URLs are
some kind of [expletive deleted] godsend idea, whereas I'm trying to tell you that
using relative URLs would *not work* for me or the majority of people
who aren't building sites but are instead just publishing their
content.

Aside from being hard-headed and simply incorrect on nearly every single front, Otto does a great job of alienating those who should constitute a significant portion of WP's target audience: developers.

Elsewhere in the thread, Jonathan Bailey underscores the core of the debate:

And this is more like the crux of the issue. Is WordPress a platform for developing webapps or a platform for people to share blog entries? I'm starting to feel as if these things are diverging....

So, I guess that's where we'll leave it. Some people feel like WP is meant to be installed by an end-user who knows nothing about its inner-workings and never should. This end-user will never change domains and his content will live-on forever. To the contrary, some people feel like WP should be "developer-friendly" and lend itself well to the enterprise Web Software Development Life-Cycle.

Like Otto said, "[We] are welcome not to use WordPress," and for projects of any size or import, we'll do just that.

Cheers for the helpful suggestions, links to plug-ins, etc., and for entertaining the debate.
Ipstenu (Mika Epstein)
Half-Elf Support Rogue & Mod
Posted 1 year ago #

Otto (presumably some self-professed WP guru).

Sorry, but that's going to make a lot of us laugh for days.

Otto works for http://audrey.co/ and ... well, I'll tl;dr it for you: Otto knows his shit, and is not a 'sell professed' guru, but actually a freakin' amazeballs coder who works for WordPress. So ... when he says stuff, you ought to pay attention.

(And yes, he can be a hard-headed jerk sometimes, and he's not what I'd call the most eloquent fellow, but that doesn't make him wrong. And I'm not just saying that cause we have plans to get a beer this summer.)
Andrew Nacin
WordPress Dev
Posted 1 year ago #

Otto isn't the only one to support absolute URLs. He is simply following a long-standing design decision of the WordPress core team. As a member, I appreciate and welcome criticism and discussion on various points.

Our current opinions on the matter are best espoused here, by the lead WordPress developer: http://core.trac.wordpress.org/ticket/17048#comment:46. I quote:

WP has used absolute URLs since the b2 days. If I had a time machine, it probably wouldn't. The main reason it still uses absolute urls is because changing doesn't seem worth the pain. The points here haven't been ignored, they just aren't enough to make most us want to mess with this when we could be doing things that people beyond those hanging out in easily amused developer circles care about. If someone wants to patch core in a manner that is fully back compat with existing URL and PATH constants as well as existing values in the DB, I'd be interested in seeing the result.

Fun thing to do: Try migrating a site that uses relative URLs when the directory it is installed in changes — or better, when the directory depth actually changes. (For maximum points, move a root install into a directory.) Finding and replacing absolute URLs in some cases is less insane because they act as nice placeholders, rather than the unfortunate regular expressions that will need to occur. Absolute URLs are sometimes more portable in the ultimate sense. Just saying, relative URLs are not without their own drawbacks.
Eric Mann
Member
Posted 1 year ago #

I was on the other side of the relative URL debate (as in, disagreeing with Otto). But there's a very important thing to understand here - developers are not the same thing as users.

Aside from being hard-headed and simply incorrect on nearly every single front, Otto does a great job of alienating those who should constitute a significant portion of WP's target audience: developers.

Yes, developers use WordPress to build sites. We spend a lot of time hacking code and migrating installations from one machine to another. But we are not the end user - our customers are.

Our customers couldn't care less about relative versus absolute URLs. They just want the software to work so they can generate content, manage sales, and drive traffic to registration forms. The majority of users (remember, WP is used to power millions of sites) will not be migrating from one box/url to another and will never need relative URLs or the cacophony of things that break when they're introduced.

Yes, relative URLs might make life easier for me. They might make things easier for you. They might make things easier for a hundred or so other developers. But focusing on a hundred or so people at the expense of millions of other users is a really bad idea.

Oh, and for the record I'll profess right now that Otto is a WP guru. His reputation is well earned in the community.
kevinjohngallagher
Member
Posted 1 year ago #

In the nicest way, I think everyone needs to take a step back here.

I disagree with Otto quite often, but I hold both him and his opinion in the highest regard. While I find Ipstenu's quote accurate, I think this can also be applied to the OP:

he can be a hard-headed jerk sometimes, and he's not what I'd call the most eloquent fellow, but that doesn't make him wrong.

With that in mind, if we're going to cut people some slack, lets also cut the people we dont' know some slack too ;)

The OP has some really good points. Absolute URLS in WP are a nightmare. Which is not to say that Absolute URLS are wrong, but our implementation of them is a royal pain in the behind.

I've talked often and loudly in the last 2 years that WordPress currently doesn't scale well, a phrase that send people into fits of hysterics. I do not mean in terms of Servers/PHP/hits, i mean in terms the number of decisions that are locked down on the basis that "they work for .com/bloggers".

Moving WP installs, having master/slave or dev/live installs and all the rest of it causes real issues. Which is fine, or acceptable, if we were to admit that and write a codex article on it. Instead we valiantly defend WP instead of being able to do anything, and just hope that everyone has the same level of knowledge and experience as we have.

Lets be honest, we get a request/moan about this at least once a week on the wp dev / hackers mailing lists. Maybe we should consider nipping this in the bud rather than just telling people that a) the decision was made in 2002 and it's not going to change and 2) it works for millions therefore nothing is going to change (unless we want it to).

TBH, we can't keep making the 'millions of users'/'scared of change' comments and roll out Capital_P_Dangit / inaccessible-menu. (not to open those can of worms)
cbj4074
Member
Posted 1 year ago #

Ipstenu, at the risk of sounding like a prick, I don't really care what Otto's credentials might be. I've seen enough to know that we disagree fundamentally on several points that extend well beyond WordPress. I've been coding at least as long as he has and if the WP core is in any way his opus, I am not moved.

Thanks for the insight and link, Andrew.

So, why didn't anybody say, "It was indeed a poor design decision, and, unfortunately, one with which we've had to live due to backwards compatibility requirements. Marcus Pope has developed a plug-in that may allay your concerns for the time being, and work is underway to address this shortcoming in the longer term."

Fun thing to do: Try migrating a site that uses relative URLs when the directory it is installed in changes — or better, when the directory depth actually changes. (For maximum points, move a root install into a directory.)

To be clear, I don't think anybody is advocating "purely" relative URLs that do not require post-processing (whether at the Web-server or PHP level). Everybody on the relative-URL side of the debate seems to acknowledge that constant-defined values would need to be prepended to the URLs whenever the content must be "exported" (that is, not simply displayed via http[s] on the server on which the content is hosted).

For those who suggest that post-processing URLs is "off the table" due to resource requirements, the fact that a stock WP installation uses 34MB of memory to serve each page request should be cause for far greater concern. But that's another topic for another thread.

Finding and replacing absolute URLs in some cases is less insane because they act as nice placeholders, rather than the unfortunate regular expressions that will need to occur. Absolute URLs are sometimes more portable in the ultimate sense. Just saying, relative URLs are not without their own drawbacks.

There is truth to these statements, and I certainly acknowledge that relative URLs are not without drawbacks.
kevinjohngallagher
Member
Posted 1 year ago #

One of the things that we did was to ensure that all hardcoded local link to posts and images was to use a simple bbcode/shortcode hook.

POSTS:
e.g. "link.com/post-name" became [site_url]post-name

MEDIA:
e.g. "link.com/wp-content/uploads/month/year/image.jpg" became [image_url]image.jpg

This made a COLOSSAL difference to us when dealing with multiple users and installs.

As a really nice touch, when we moved to using a CDN for our images, we simply replaced IMAGE_URL in the config file and BAM, no database issues, it automatically pulled all images from the CDN URL.

I know this sounds like a daft statement, but given that we can (and should) be defining SITE SPECIFIC information in the WP config file doesn't it stand to reason that something as purely site specific as site_url should be defined there too? Coding issues aside, that just seems sensible...
zamoose
Member
Posted 1 year ago #

I'm struck with an idea:

Why not do something similar to what Mark Jaquith's Markdown On Save plugin does? It stores the final rendered content in the normal places, but stores the Markdown in post_content_formatted, so that if the plugin ever gets deactivated, no rendering impact is felt.

Why not do something similar for relative vs. static links? Store shortcode-style prefixes, render to HTML on save and be done with it?
kevinjohngallagher
Member
Posted 1 year ago #

Fun thing to do: Try migrating a site that uses relative URLs when the directory it is installed in changes — or better, when the directory depth actually changes. (For maximum points, move a root install into a directory.)

Actually, I think this is wrong and a little old fashioned. We recently moved 2 different CMS' (on different platforms) with a mixture of relative and referenced links and it was smooth as silk.

You see, there is a 3rd option: Absolute, Relative and "referenced".

We already have the site_url as a reference point that we can refer to at any point on the loading of a WordPress page (even prior to initialising the DB is people define it in the WP_config which they should always do); so the questions remains as to WHY we would hardcode ABSOLUTE URLs when we could just reference the URL at any given moment?

I'm not advocating a change, it just seems to me that rather that take the 'extendable' solution, the core team took the lead from a decision made by B2 in 2001/2002, and continued with a solution that only worked in 1 situation.

More importantly, I think it's a little (unintentionally) disingenuous to be pointing out the 10 year old decision, when the MAJOR culprit of the absolute url issues are:

1) Local links to posts in the content editor (added in 3.1)
2) Local links to media in the content editor via Media manager (added in 3.3)

90% of the Absolute vs. Relative vs. Referenced URL issues could have been cleared up in the last 18 months with 2 quick fixes.

The bigger issue is not about absolute URLs, but about hardcoded URLS in multiple places with multiple dependancies. Why not have URLs reference a single place (site_url)?
Eric Mann
Member
Posted 1 year ago #

One of the things that we did was to ensure that all hardcoded local link to posts and images was to use a simple bbcode/shortcode hook.

POSTS:
e.g. "link.com/post-name" became [site_url]post-name

MEDIA:
e.g. "link.com/wp-content/uploads/month/year/image.jpg" became [image_url]image.jpg

Is this shortcode solution available as a plugin? I have a feeling it would satisfy the devs/users who need such a solution without needing to draw on this debate over absolute/relative/referenced URLs in core.
Samuel Wood (Otto)
Tech Ninja
Posted 1 year ago #
Can you guys not talk about me while I'm hungover? It hurts my brain. ;)

In other words, I would prefer that WP store the siteurl and home values in wp-config.php, as opposed to the database.

Add two lines to your wp-config.php file:
```
define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');
```
Magic.
kevinjohngallagher
Member
Posted 1 year ago #

@Eric:

I'm afraid it's not available as a plug-in as many our EnterPress (poor name, we thought it was funny at the time) functionality required Core Hacks. I'm happy to flesh-out what we have next weekend and use an "on_save" hack to replace... I'll see how bad it looks.

More over though, I think this is a good debate to have, though I appreciate some folks haven't enjoyed the tone of the OP, I know I'm one whose tone isn't always loved either ;)

If you excuse my very poor translation "la partie émergée de l'iceberg" is the french equivalent of the English "tip of the iceberg", but it actually as a phrase has a very different meaning in context.

The french use it almost as a warning to mean that you've only thought of the bit you can see; while in English its more of.. we know there's more to sort later.

While continuing to make me even more unpopular than I already am, I am strongly of the opinion that "we" (for the most part the Core team and those whose opinion they like - but there is some community involvement) solve issues by numbers: i.e. What will solve this issue for 80% of users?

The problem is, as I'm often told, if 50% of WP users are on ".com" there is NO possible way that a solution will enter into WordPress until it leads to a huge RoI from ".com"/bloggers. The problem with that 80/20 rule is that 20% of over 20million = millions of edge cases.

What I struggle with is that the conversations I see never evolve round how much work is required to done something the "right/extendable" way, to work out if it's worth the Return on Investment; instead they focus on how much development time there is to make things work. Sometimes, a very small amount of work is required to make something extendable enough to cater for the other 20%.

Take my example for a second of using a shortcode instead of hardcoding the URL when we added the internal-linking in 3.1 or the new media manager in 3.3. We all know I'm the most faded low watt bulb in the box, especially in comparison to some of exceptionally bright people in this thread - but holy crap - I can't have been the only person who thought of NOT hardcoding something. I mean, NOT hardcoding seems almost more obvious than hardcoding things. More over, I raised it as an issue to a WP core developer after 3.1 came out. *tumbleweed*

Thats my big thing, heck its always been my big thing. My business card says "failed developer" on it (thats not a joke), and I will always bow to y'all on what can and cant be done technically. But far too many of our decisions in the last 2 years have been short-term and ".com" focussed. Conversations like this, even if they start in a bad place, have the potential to provide a solid understanding of the pain points that those of us using WordPress "in the wild" are facing.

I am reminded, often, of this:
http://kevinjohngallagher.com/2012/01/listening-core-skill-learning/

@ Otto:

Thats awesome bro :)
Now where does that get referenced instead of the database for every call?

You forgot:
define('WP_VARIABLE','does_not_matter_as_its_been_hardcoded_multiple_times');

;)

(trying to keep it light incase you're still hungover)
cbj4074
Member
Posted 1 year ago #

Kevin, while I appreciate the fact that you seem to agree that the status quo is less than ideal, I'm not sure why my tone is of particular issue to you.

I didn't come in "guns blazing". I began with a pragmatic post that was intended to be inert of tone or bias. If you read the first paragraph of my second post, this fact should be evident.

It was after I was told several different ways, "That issue does not exist", "You're doing it all wrong", "That's a stupid thing to do", "Learn to do XYZ", and similar that my tone changed.

Moreover, when someone (not you) implies that I should bow to another developer because he is the best developer that ever lived, and everything he does is impervious to scrutiny and criticism, it doesn't make me want to contribute to any community of which said member is a vocal part. Especially when all evidence is to the contrary.
kevinjohngallagher
Member
Posted 1 year ago #

cbj4074,

Genuinely no offence was meant, and I'm almost fine with your tone (for the most part). But on a support forum, especially with lovely volunteers such as Ipstenu, manners and tone go a really long way to smoothing the waters. This wasn't very nice though:

at the risk of sounding like a prick, I don't really care what Otto's credentials might be.

Its funny, I was introduced as "The Most Hated man in WordPress" (trademark) at this year's WP Scotland event because my tone is about as harsh as the WP community can take. More than any other community I've ever been involved with, the WP community is "sensitive", and it's very important to end your sentences here with smiley faces or emoticons if you're going to say something thats not 100% inline with the status quo :)

Ipstenu, Andrea, Andrew Nacin, Eric Mann and Otto are all people who i've strongly disagreed with over the years about one thing or another (heck Ipstenu and I used to go at it about bbPress back when that was a real thing and not a figment of the WP plug-in directories imagination); and they're all people I respect the heck out of even when we don't agree.

I think we all agree that WP isn't perfect, but there's a very specific tone that these good folks respond to, and a particular phrasing that gets a good deep-dive response. It'll take some time to nail it, and while folks like me cant help but bring up f*** ups like Capital P Dangit making every arabic wordpress site blasphemous because some crazy Texan only thinks in a limited viewpoint, you can join me on the naughty step ;)
cbj4074
Member
Posted 1 year ago #

Kevin, I'm not the least bit offended by your remarks, but I appreciate the community backgrounder all the same.

You seem like a nice guy. In fact, I'm sure I'd have a rollicking good time with anybody on these boards were we to meet over a beer at a WordPress event. That said, I have no intention of pandering to sensitive egos where software development is concerned (nor community support, for that matter).

I'm not suggesting that there's no place for general politeness, but placating "VIP" community members is of little interest to me. I contribute the bulk of my free time to libre and gratis open-source software projects, and I've "seen it all" in the way of community dynamics. The communities in which the members keep their discourse terse, their posts factual, and their feelings on the side-lines are the most productive. If it wasn't obvious, I'm not here to make life-long friends and prepare for the next meet-up.

Perhaps my perceived arrogance stems from the fact that I am sufficiently qualified not to rely on anybody here for help. I was providing feedback, not asking for assistance. I attempted to do so in a nuts-and-bolts manner, stating only the facts, and even offered a potential (if not partial) solution. As cold as it may sound, I have no investment in WordPress's future, and its fate is not something over which I lose sleep.

If anybody ought to be given tips on decorum, it is the "respected" WP community members after they alienate new members who are probably as qualified as their most heralded core developers (if not more so in some cases). One never knows who's behind the keyboard and who could be a star contributor.

Anyway, we've derailed the thread sufficiently, so I'll leave it to those who are still being productive. And a :) for good measure.