Things are starting to look a bit ugly around here. I’ve begun the move over to the third release candidate for textpattern, but it looks like it’s going to be an interesting ride.
I had made quite a few tweaks to my last Textpattern install, so it’ll be interesting to see how the old posts make their way over to the new install.
I’ll update this post as things progress. Please bear with me. If you see broken stuff, please don’t tell me yet.
Update, 08.07.2005
OK, after a few teething problems, textpattern has started to behave a bit better. Things have now gone a little bland – I’ve removed all the wonderful blue-ness this blog had. I’ve decided to ware down the design bit-by-bit, so that I can keep some form of layout for now to keep things readable.
I’ve also re-instated a few of the tweaks I made to RC1 (I’ll be keeping a better log of changes this time, to make future upgrades easier):
- Added a bit of flexibility to the comments.
- Cleaned up comment numbering so they follow logical numbering within each article instead of using the comment ID.
- Made a mild tweak to the comments invite link. I’m pedantic and like to use ”#comments” instead of ”#comment”. It makes more sense to me!
- Set up my personal comment style.
- I’ve removed the alternating comment boxes though – I don’t think I’ll be using them this time around.
- Content negotiation is back, but I’ll probably remove this soon and just serve pages as good ol’ HTML 4.01. This site won’t validate in the meantime – there are still changes to be made.
Anyway, I think this redesign is going to be a slow process. I’m hoping to experiement a little and involve readers in the design process, what with general design being one of my weak points. Feel free to contribute.
7 Responses to “Live Redesign, Step 1: Moving to Textpattern 1.0RC3”
Broken stuff? Does that include your weird and warped mind mate? 😉
That’s always been broken.
How are you making changes to the code – are you amending the actual PHP code of existing functions or creating your own functions and installing them as new plugins?
I’ve been doing the former, but I wish I’d done the latter now – making your own personalisations in the form of plugins would mean that come the next upgrade (or server meltdown!) you have all the personalised functionality in one place, rather than having to remember all the little changes you made over the years.
I know what you mean, and I had considered this. However, I must admit to not having a clue how textpattern plugins work (I can use them, but making them I mean), so all my tweaks have been within the code itself. I’m a developer, that’s what I do. e.g. I wouldn’t know how to make it so that the comment numbers come up in sequence through articles rather than by site-wide comment ID.
Using an API is almost always a better way to do things, but sometimes its just not possible. Most of my work with Drupal has been through the API, but some has had to have been hacking core code to get some flexibility I needed. Means a bit more work for me when a new version comes out, but it means I can do what I need to now rather than at some time in the future.
AFAIK Textpattern plugins are simply a matter of copy+pasting the code of a function into a conversion page, which then spits out the text string that is the plug in.
Conversion page is here: http://textpattern.com/plugins/txp_plugin_template.txt
Thanks Matthew. I’ll take a proper look at that later. Some of the functions I’ve been messing with have been well-rooted in textpattern, so it’s just been easier for me to hack away. But as I’m working with a fairly fresh install, using plugins might well save me hassle in the future. Worth trying at least. Cheers mate!