3 August 2006, by Chris
I'll be setting up WordPress and then integrating existing XHTML and CSS into a WordPress theme. 
So, the existence of this blog indicates that I’ve been reasonably successful in setting up a WordPress blog for the first time. I’ve heard a lot about the system before, but this is the first time I’ve got my hands dirty with WordPress.
We’ve already got a site set-up (exponetic.com) so I won’t be concerning myself with design, or building the CSS and XHTML with this post. I’ll simply be setting up WordPress and then integrating the existing XHTML and CSS into a WordPress theme. I’ll write up the theme creation when I get a minute.
The WordPress site and general operation seems good (what you would expect from a modern open source effort), although I’m not totally convinced by the design and it’s often inordinately large font, but so be it. I guess it’s meant to be good for usability.
The download and install seemed to me very simple. They boast a ‘famous five minute install’ which (as long as you’re confident on the Linux command line) is reasonably true.
I’m using a Debian server. I log in as the www-data user (so everything is owned by the right user when I set things up) and then cd to make sure I’m in my home directory, which should be /var/www. As the site is already set up, I’m going to make a blog/ directory to house the blog. After navigating to the htdocs site directory, I make the directory mkdir blog and then cd blog into it.
So now I need to download WordPress.
wget http://wordpress.org/latest.tar.gz
You should see the file download.
Then unzip it. tar -xvvzf latest.tar.gz
Then set up your database and finish the install. All this is covered on the official WordPress web site.
Next, I’ll look at the re-skinning process, but that will have to wait for another post.
August 3, 2006 at 10:14 am
Filed in: Design, Front-end, PHP, MySQL, Open Source
No comments
30 September 2005, by Karl Bunyan
For some reason, Zend have decided not to make PHP throw an exception when you try and load invalid XML into a DomDocument object... which is annoying.
For some reason, Zend have decided not to make PHP throw an exception when you try and load invalid XML into a DomDocument object. This includes XML with invalid characters e.g. &. This means wrapping a try/catch around anything does absolutely no good whatsoever, which is annoying.
Is there a good way of trapping runtime errors using loadXml with the DomDocument library?
September 30, 2005 at 10:42 am
Filed in: PHP, Programming
No comments
3 August 2005, by Karl Bunyan
It's obviously a bit hacked together behind the scenes, as exemplified by the fact you can't do things like $this->getThing()->getOtherThing() without it barfing.
After working with PHP 5 for quite some time now, I’ve had to go back to PHP 4 to develop a CMS for a client’s site where we don’t have much over the hosting environment. Going back to the old version has annoyed me quite a few times already and it’s probably made worse by the fact that I never really did much PHP 4 anyway (I’m quite new to the language, even though I have been programming in it on and off for 2 years) and lately I’ve been working in a combination of PHP 5 and C# (as well as various others) and generally being a bit more object oriented about everything.
First off there’s the whole not really object orientedness of PHP 4. PHP 5 isn’t that object oriented, but PHP 4 is miles off. Passing variables by value instead of reference unless you put stupid & symbols everywhere… whose idea was that? Also it’s obviously a bit hacked together behind the scenes, as exemplified by the fact you can’t do things like $this->getThing()->getOtherThing() without it barfing. Instead you have to put the returned value from the first thing into a variable and then call the next method… not a good sign in an interpreter.
You can just about force yourself not to access member variables of objects directly, even if you can’t set things to be protected or private, and make get() and set() methods everywhere, but sometimes it’s really useful to put things into static classes. Database routines would be really useful, for example. Instead I’ve taken to creating a great big global variable to hold an object and refer to it everywhere and use the member variables of that object to store other useful objects. At least methods can be called statically, but without static member variables they’re not as much use. (I use a similar technique when programming in Lingo to save having to reference all my globals in each script: store them as properties of another object that keeps state for the whole application.)
And very little XML support either… Even ASP could handle XML well, and even XSL, four or five years ago, and ASP as we all know is the lowest form of programming language ever invented. (Okay, there are worse languages than VBScript, but not many that site behind so many important web sites. I once worked on a half million pound project that was built in ASP… Scary!)
Rant ends
August 3, 2005 at 10:40 am
Filed in: PHP, Programming
No comments
3 August 2005, by Karl Bunyan
The value of the position property in the original object will remain unaffected. This is quite rubbish. To get round it you need to get all the array keys and then create a separate variable to store a reference to the object you want to change.
PHP 4 doesn’t seem to create references for objects in foreach loops. e.g. the following will not change the original objects:
foreach($placeholder as
$contentBlock)
{
$contentBlock->setPosition(1);
}
The value of the position property in the original object will remain unaffected. This is quite rubbish. To get round it you need to get all the array keys and then create a separate variable to store a reference to the object you want to change:
foreach($placeholder as $key => $value)
{
$contentBlock =& $placeholder[$key];
$contentBlock->setPosition(1);
}
The variable $value isn’t used at all but if you’re stuck using PHP 4 then this is the best you can do. Luckily PHP 5 works much more sensibly, but we don’t always get a chance to use that so I’m stuck with this slightly messy alternative.
Foreach in the PHP docs
August 3, 2005 at 10:38 am
Filed in: PHP, Programming
No comments
18 June 2005, by Karl Bunyan
PHP 5 doesn't seem to attempt to implement any kind of inheritance for properties within static classes. This can be mean having to duplicate code within static subclasses.
PHP 5 doesn’t seem to attempt to implement any kind of inheritance for properties within static classes. This can be mean having to duplicate code within static subclasses. As an example, we would like to have a parent class (this is using the Singleton pattern) such as this:
abstract class DataTable
{
protected static $instance;
protected function __construct()
{
parent::__construct();
}
public static function getInstance()
{
if(!isset(self::$instance))
{
self::$instance = new self();
}
return self::$instance;
}
}
And then to create a subclass to inherit from it:
class PageTable extends DataTable
{
}
And then creating an instance of PageTable could be done by running a line of php such as this:
$pageTable = PageTable::getInstance();
Which would then return an instance of PageTable.
Then we might want another subclass such as:
class ContentTable extends DataTable
{
}
And so be able to create an instance of ContentTable with:
$contentTable = ContentTable::getInstance();
However, what really happens is that first PageTable::getInstance() is called and since PageTable itself doesn’t have a method defined as getInstance() the parent method is called. This sets $instance as a reference to the newly created object. However, the $instance property belongs to DataTable and not to PageTable. Even declaring a $instance property local to PageTable has the same result as in this case self::$instance refers to the parent class (which is where the method is run from). Thus when ContentTable::getInstance() is called, the value of self::$instance is detected as being set and the original instance of PageTable is returned. This is obviously not the intention.
The only way around this is to duplicate code by adding an $instance property to each subclass, as well as a duplicate of the getInstance() method.
As an aside, the same is also true of class constants which are also referred to with the self:: caller. From this we can infer that self:: always refers to the context of the current code block not the class from which a method is called.
June 18, 2005 at 10:37 am
Filed in: PHP, Programming
No comments