cbj4074

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.

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.

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.

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.

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.

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

Ditto if I install it in https://example.com/wp/ but use https://example.com/ as my front facing URL. All my posts will be https://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. https://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).

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 https://localhost/project (the fully-qualified path to WP’s index file is https://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., https://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', https://localhost/project);
update_option('home', https://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.

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.