Archive for November, 2007
Since I started working my way back into WordPress, and the community, I have noticed a number of blogs talking about ‘Premium’ themes. I have no idea what that means, so I decided to find out.
Premium has always seemed to me to be one of those annoyingly meaningless marketing words designed to separate normal, from not as good as it should be. Perhaps I am just a cynic, but does the existence of ‘Premium’ themes mean themers are deliberately hobbling their non-‘Premium’ themes? or is it just a reference to cost?
Nathan Rice takes the view that Premium Themes are those of “higher quality and customization potential
”. Although he doesn’t explain exactly what he means his post makes it clear that in his view part of the role of a premium Theme is to extend the potential of WordPress. More of a feature set than a theme by itself.
That’s the kind of concept I can buy into, unfortunately while that view seems to be repeated regularly on theme sites, and blogs, it often precededs a host of surprisingly ordinary themes (although they are sometimes very nice looking and possibly worth the money on that alone).
It isn’t even the fact that a lot of these paid-for themes are calling themselves premium while seeming to deliver very little extra. While searching for Premium Themes I have found free premium themes that don’t deliver very much either, and free premium themes that do deliver.
It seems to me that the label is being used differently by different people. Some use it to refer to the features of a theme, some use it to refer to the cost, and some use it to refer to the effort involved, either way it isn’t really a useful label any more for someone who is looking to buy, if it ever was.
My conclusion, or at least my feeling about it, is that a premium theme should be something special. It should be something like News Pixel, News Theme, Revolution, or Showcase. It should give you the tools to redefine your blog, not just pretty it up a bit.
A premium theme should give you so much scope that you never need another theme again. It shouldn’t hold you back, but equally shouldn’t be something you can easily throw away. That may not be a useful definition, but I’ll stick to that in future.
PHP 5 has been around for a long time now but it still isn’t getting the takeup that you would expect from the newest version of one of the most popular languages around. There has been some debate about WordPress and PHP 5 over the past 6 months, and I couldn’t go as far as some of them and suggest ignoring PHP 4, but that’s not to say the advantages in PHP 5 should be ignored either.
PHP 5 offers some advantages over PHP4: Better database support, better xml support, better object support not to mention that PHP 6 is not massively distant and will not be as backward compatible as version 5 so any step in the right direction must be a good thing, right? The changes will need to happen eventually.
Because of this, and the fact that I quite like PHP 5, I would quite like to see a PHP 5 only version to run along side the current version.
The benefit of this approach is that, as it is already PHP 5 compatible, nothing needs to change just yet. Just be separate.
I think there would be benefits in freeing up developers who want to work in PHP5 to offer additional (core or otherwise) functionality for that version only. They would be free then to optimise for 5, rather than just being compatible with 5, and to produce plugins that worked on that version alone.
Part of me likes to think that if these developers hit on a seriously good piece of funcationality that this would help drive migration to PHP5 as self-hosters looked for hosts with the appropriate installations but that might well be wishful thinking on my part.
What do you think? do you care? is it too much effor for too little gain? is it a good idea? let me know.
Since I started this blog I have been getting trackbacks from dubious sources, blogs that are clearly ripping off my content. I have also had trackbacks from blogs ripping off the content of other blogs that linked to me. Lorelle has written about these new kinds of spammers, it is clearly a problem.
One of the solutions pointed to is ©Feed plugin.
The plugin allows you to add a message to the end of your feeds, that don’t appear on your site. A digital fingerprint the readme file calls it. The idea being that it makes it easy to track, and therefore deal with the sites that are using your work for their benefit.
It also promises to scan some search engines for the fingerprint code to give you feedback.
I intend to try this out for a little while and see what results that brings me. I will report back.
In the meatime I would be interested to hear whether you have used it and what your impressions of it are.
So you’re writing a plugin that uses an object to maintain the state of your application, perhaps the object is used to construct a document, or a menu, or something else entirely, and your application requires multiple form submissions. How do you maintain the state of your object across submissions?
There are lots of ways to do this, use sessions, use hidden fields, recreate the object manually with each postback. Which method proves most obvious depends on your background, and experience. The most usual for PHP, is to use session variables to save the data
For the examples I’m going to create an object with four methods: getters and setters for the internal data, one to save the state and one to reload it again, exactly how and when these are called may differ depending on circumstances.
class myClass{
//the array the data will be stored in
var $collection = array();
function getVar($name){
if ( isset($this->collection[$name]) ) {
return $this->collection[$name];
}
}
function setVar($name = '', $value = ''){
$this->collection[$name] = $value;
}
function loadState(){
if ( isset( $_SESSION['myClass_state'] ) ) {
$data = $_SESSION['myClass_state'];
$this->collection = (!empty($data['collection'])) ? $data['collection'] : array();
//repeat for any other data maintained
}
}
function saveState(){
$data['collection'] = $this->collection;
//add any other internal data in the same way
$_SESSION['myClass_state'] = $data;
}
}
These methods can then be called after checking to see whether the form is actually being submitted.
$myClass = new myClass();
if ( isset( $_POST['submit'] ) ) {
$myClass->loadState();
//make any changes dictated by the information that has been posted
$myClass->setVar('post_title',$valueSubmitedInForm);
$myClass->saveState();
}
An interesting alternative to this, which I haven’t used in anger but have considered, is to use hidden forms to contain the same data. Instead of saving the information in a session variable the data is serialized, base64 encoded, and added as the value of a hidden field.
There are more security issues with doing things this way though so it is probably best avoided.