WordPress does a pretty good job making things configurable just about everywhere – either via plugin or options in the admin side of things. There are a few exceptions however, and I was wondering if it would be reasonable to consider an semi-hidden group of settings similar to those you can access in Firefox via the about:config screen. In other words, settings that only the technical would access – with a “use at your own risk” disclaimer of sorts. To easily maintain overridden settings between upgrades, you could just set your override values in a plugin.
Something I’d like to propose for this type of setting is the ability to turn off the “each post slug must be unique” functionality. Yes, there is a plugin that sort of fixes this; however the “fix” occurs after the pingbacks and trackbacks have been sent. As a result, I’ve stopped sending pingbacks or trackbacks from my “Around the web” posts as the post link being sent is later “fixed” to remove the number.
I understand why it makes sense to have code in the WP core to “save the users from themselves”, but if I’ve set up my permalinks so that I know I won’t be creating collisions by using the same post slug – I want an easy way to accomodate this as well.
What do you think? Good idea? Not? I guess it’s too late to submit a patch for 2.0 anyway, but I wanted to put the idea out there.
UPDATE: To clarify, I’m talking about situations where an option might be confusing for casual users, or something (like requiring unique post slugs) is in place to protect people from shooting themselves in the foot, but a valid argument can be made in the mind of the developer implementing the feature to allow the alternate functionality. In these situations, the dev could simply add an option (to the vars.php file perhaps) and structure their code accordingly. If someone needs to flip around the way it works, they can simply override the variable in a plugin. It avoids adding upgrade complexity and clutter in the options screen, but still allows for clean override ability.
Hi!
I think it’s a great idea and I would sure use it for whatever it can (I love hidden functions ;))
If it’s too late for 2.0, maybe it could be done for 2.1
You have already yourblog.com/wp-admin/options.php which lists every option available, including some that are not available via standard option pages. This is a “use at own risk only” page 🙂
Sounds good, I’m not a big WP hacker but it would be good to have a central file to change core settings and such.
Ozh – those are the options in the database. Adding database options is much heavier weight than adding options in the code.
It wouldn’t be hard to do a page that dumps wp_options and allows you to change any of them, although this wouldn’t really be the functionality you’re looking for as things like page slug uniqueness don’t go through the options anyway.
By the way, in 2.0, categories aren’t blocked from having the same slug as long as their URIs don’t collide, the same should be true for pages soon.
Much of the point of my suggestion is having the variables in a file rather than in the database. This allows the devs more freedom to add configurability on the fly without having to write (or require users to run) upgrade scripts, etc.
Well the proper fix to your problem at hand is to have WP check the full URL for uniqueness, not just the slug. It should examine the permalink structure you have setup, not just the slug.
Hmmmm….*digs into the WP core*
I believe that wordpress have been developed to be easy to use no matter what, just one, two, ready, righ?
So, if you want to have some core changes i guess you should either use a master plugin to handle those “extra” options or just get into the core files and do your magic.
I’m using the first option, i have a plugin with all my custom functions and hacks together that i keep everytime i upgrade.
Chris, permalink structures can change. This was discussed at length on the wp-hackers list, I recommend check out the archives on this issue.
marcoss, functions can be overridden – procedual code just happens and the core files need to be modified. I’m suggesting that some of this procedural code be made configurable.
I know that an about:config-like option panel would be welcomed by many. For the ubergeeks, it would be total Nirvana and for the less technically inclined, it could be something that is out of sight and out of mind.
It’s the best of both worlds, really. I would certainly support something like this being done!
Alex: I’ve checked with my svn-latest test blog, and WP no longer forces page slug uniqueness. Neither does it with categories. There’s actually no code to check against the entire URL either, but that’s an ommission.
David House – according to trac.wordpress.org in trunk, you are incorrect. See the $post_name_check portion of wp_insert_post().
Regardless, this is just one example.
Aha. I thought you were talking about page slugs, which don’t have to be unique. That check only applies to posts.
Never mind then. 🙂
All in favour say “aye”. *raises hand*
Hidden options are an excellent idea in principle. Thunderbird enables you to enter a variety of statements into JavaScript files, thereby customising the mail client quite endlessly (introduction phrase, symbols, etc.). Whether these hidden option are implication of an advanced option that is not yet implemented, I can’t tell. Either way, it is a selling point to anyone who feels passionate about hacking or even requires certain customisations.
For example, I know I would be deterred by a client that does not handle exectutable/dynamic signatures and I also feel uncomfortable having no control over the X-headers. I currently use 3 mail clients in tandem (KMail, Thunderbird, Horde) because none offers all the required features. Thunderbird with its hidden options and plug-ins is yet the most powerful/flexible.
As regards hidden options in general, the only issue I can think of is increased complexity in the code. Many conditional statements and more parameters/values which are not hardcoded make code flow harder to keep abreast of. Support for multiple languages has a similar effect. Having said that, since broadly speaking, those to ever look at the code know what they are doing, I think it is balanced by the positive points, if not overwhelmed by them.
Nice suggestion.
Should We Have Hidden Options?
Alex King has recently suggested that we have an about:config for WordPress. When I first thought this I thought “great!” because we’ve had this for several versions now: if you browse to options.php directly you can edit any option i…
I suppose, in theory, we already allow this. WordPress isn’t a compiled program meaning that if you want something changed, you hack the source. I’m not condoning putting a nice interface on top of this, just something to think about.
David House, I believe I explain why this is an alternative to hacking the source several times… please take the time to read the post more carefully.
Alex: I’m not sure you have. I can see that you’ve explained it as an alternative to writing a plugin, but if you want something specific and unique to just you, then I don’t see any reason why hacking the source shouldn’t be ruled out.
If I’ve misunderstood something, then sorry in advance, and could you point me toward the part of the post where you explained that? Thanks 🙂
It would probably be really easy just to make a plugin that makes a page that dumps stuff from the wp_options database table into an interface like Mozilla’s about:config. No “what this does” stuff, just the variable name and change the value.
It’d be useful for stuff that isn’t supposed to be modified by the average user, but can be useful for more experienced users.
shorty114: that has already beeen suggested and indeed has existed for several versions now. Just browse directly to wp-admin/options.php. However, that doesn’t cover the things Alex talked about in the post, as things like post slug uniqueness don’t go through the options table at all.
I’d LOVE to have something like this.
Textpattern has something like this called “Advanced Preferences” (though even their “Site Preferences” looks more complicated than most preferences, options, or settings pages ought to look). I’d link to an example, but documentation is pretty sparse.