What’s New in WordPress 2.0? · Asymptomatic - even though I will soon be leaving WordPress, it's always interesting to see what's going on there. Besides, at least the Metaeule will certainly continue to run with WordPress.
cms
A Few More Pictures ...
... there is in my CMS Testbed(yes, I'm knitting on my own content management software again). And when I look at how little trouble my own software gives me and how much trouble Wordpress always causes (for example, today I couldn't upload any pictures without being able to find any reason - nothing in the log files, no error message, just the refusal to upload), then the switch could be getting closer and closer ...
Virtual Hosts with WordPress
The Vhost Plugin is my current favorite of the entries for the WordPress Plugin Competition. With this plugin, you can bind categories to virtual hosts - when this host is accessed, the appropriate category is automatically displayed and optionally, a different template can be applied to this combination.
I can think of a whole range of ideas spontaneously - for example, I could put my Bananenrepublik under it and present my rants as more independent content. Or I could finally run my photographic entries under one of my photo domains again. I think I'll play around with the plugin soon.
Another funny feature - but rather uninteresting for me - is the possibility to restrict a user to a VHost (and thus to a category) and set up a multi-blog platform on a WordPress installation. Could be quite funny for family blogs, for example.
Unfortunately, the installation is a bit tricky - you have to patch a few functions because there are bugs in the standard installation. With WP 1.5.1, this should hopefully be better.
PIXELPOST - Small Photoblog Software - looks quite nice, as do the demos. Fun is the small strip calendar in the demo - I think I'll do something like that for WordPress, it takes up significantly less space in the sidebar than the classic calendar. For someone who just wants to photoblog, PixelPost looks quite nice.
New Game, New Luck: b2evolution
Today I took a look at b2evolution (as usual, just a brief superficial test flight). It's related to WordPress and that alone is interesting - let's see what others have done with the same base code. So I got the software, grabbed the Kubrick skin (hey, I'm liking Kubrick these days), and got started.
What immediately stands out: b2evolution places much more emphasis on multi-everything. Multi-blog (it comes pre-installed with 4 blogs, one of which is an "all blogs" blog and one is a link blog), multi-user (with permissions for blogs etc. - so suitable as a blogging platform for smaller user groups) and multi-language (nice: you can set the language for each post, set languages per blog). That's already appealing. The backend is reasonably easy to use and you can find most things pretty quickly.
But then the documentation. Ok, yes, the important stuff is documented and findable. But as soon as you go deeper, almost nothing is self-explanatory or documented. Ok, I admit I shouldn't have immediately set out to make the URIs as complicated as possible - namely via so-called stub files. These are alternative PHP files through which everything is pulled to preset special settings via them. Apparently you're supposed to be able to get a URI structure like WordPress with it - the b2evolution standard is that index.php always appears in the URI and the additional elements are tacked on at the end. That's ugly. I don't want that. Changing that apparently only works with Apache tools done by hand (no, not like WordPress's nice and friendly support for the auto-generated .htaccess file) and then corresponding settings in b2evolution. Ok, you can do that - I know Apache well enough. But why so complicated when there's an easier way?
Well, but the real catch for me comes next: b2evolution can only do blogs. At least in the standard configuration. Exactly - just lists of posts ordered chronologically. Boring. Not even simple static pages - sorry, but where do I put the imprint? Manually created files that you put alongside it? Possible, sure. But not exactly user-friendly.
There are also some anti-spam measures, for example a centrally maintained banned words list (well, I personally don't think word lists are that suitable) and user registration. Not much, but sufficient for now. You can certainly do more via plugins. Speaking of plugins, there's a very nice feature to mention: you can have different filters activated for each post. Each time anew depending on the post. Very nice - WordPress has a real deficit there, the activated filters apply to everything across the board - one change and old posts suddenly get formatted wrong (if it's an output filter).
Also nice: the hierarchical categories really behave hierarchically - in WordPress they're only hierarchically grouped, but e.g. not much is done with the hierarchy. In b2evolution, posts from a category automatically move to the parent category when a category is deleted. Also, thanks to the multi-blog feature, you can activate categories from different blogs for a single post and thus cross-post - if it's allowed in the settings.
Layout adjustments work via templates and skins. Templates are comparable to the WordPress 1.2 mode and skins are more like the WordPress 1.5 mode. So with templates everything is pulled through a PHP file and with skins multiple templates are combined and then the blog is built from that. Special customizations can then be done via your own stub files (the same ones that are supposed to be used for prettier URIs) and via those you could, for example, build fixed layouts with which you could simulate static pages.
All in all, the result of the short flight: nice system (despite the somewhat baroque corners in URI creation and quite sparse documentation) for hackers and people who like to dig into the code. For just getting started directly, I find it less suitable - WordPress is much easier to understand and get going with. And to compete with Drupal, b2evolution is too thin on features - just too focused on blogs. You can certainly bend it in the right direction - but why would you want to do that when you could just use something off-the-shelf that can already do all that?
Hmm. Sounds relatively similar to what I wrote about b2evolution almost a year ago. There hasn't been much development there in the meantime.
phpOpenTracker is a live access analyzer for websites. It can be integrated directly into PHP applications or data can be collected from static websites via web bugs (small invisible graphics). You can use it to learn quite a lot about user behavior on websites. And Asymptomatic is currently working on a WordPress plugin for it, which will allow you to see the corresponding evaluations in the WP backend...
Etomite Content Management System
The Etomite Content Management System (found via Netbib) is quite an interesting affair. What I don't like so much about the CMS: the default theme. Sorry, but it's colorful and looks to me like Windows. Besides, it uses a table layout, which I also don't like so much. But otherwise I have to say, this thing has something to it. The backend in particular is very interesting - it uses JavaScript and DHTML extensively, which of course isn't so great if you don't like JavaScript. But it offers a whole lot of interactive features that are quite nice - for example, feedback on ongoing actions, automatic updating of various interface elements, and overall quite smooth operation.
I also like the idea of snippets - something like nuggets in PyDS. Small code snippets that you simply store in the database and then retrieve in templates via tags. Very practical, as you can often build simple smaller extensions this way without having to reinvent the wheel.
The automatic caching is also quite interesting - nothing really new, but in this case a nice idea: you can specify for the elements themselves whether they should be cached or not. And for each element individually. Significantly better than the usual all-or-nothing approaches of other CMS.
Overall, Etomite is much more full-CMS-oriented than blog-oriented. Functionally, that puts it more in a group with Drupal than, say, WordPress. There are already a number of snippets for easy extension, as well as themes. Various language files already exist too. Documentation exists as well, and even at first glance it's quite usable for getting started.
The license is GPL, which is good. However, a special notice appears on first login that cannot be removed - actually, something like that conflicts with the GPL, because the GPL specifically says that I can do pretty much anything with the package, as long as I make the modified source available. Ok, I can't claim it's from me and I must preserve original internal copyright notices, but otherwise I can change everything. And that normally includes notice texts. Forced links and forced notices are simply incompatible with the GPL. Either you have to explicitly extend the GPL to include this notice - which then makes it a GPL+addendum that becomes incompatible with the standard GPL - or you refrain from forced notices. This is a not unknown problem for people with the GPL, but something like this can definitely be troublesome in commercial use.
Has anyone ported Kubrick to Etomite? I'd need a somewhat nicer theme than the one supplied for my experiments.
More on Drupal
What I also noticed while tinkering with Drupal: unlike WordPress, the database model is quite complex. WordPress is pretty straightforward - just a few tables with data in them, most of it quite straightforward. If you want to change something, you can always fiddle with it at the SQL level and write import scripts, repair scripts, etc. Everything is always calculated on the fly - counters, lists, etc.
Drupal, on the other hand, uses quite elaborate caching mechanisms in the database. Things from the filesystem are also cached. This means that with small scripts you have more work to do, because you have to account for much more - at least remove the cache so it gets reconstructed. Also, the data model is much more denormalized. That's certainly good from a design perspective - but for small scripts it's more cumbersome, since you have to handle more places.
This is now not a judgment, just an observation - both have advantages and disadvantages. The advantages of the Drupal approach seem to show up in performance, which seems to be somewhat better than WordPress not only because of the somewhat cleaner PHP structure (though I don't have hard numbers on that - first I need a workable import script for my posts to work with the same approaches).
What I also noticed: PostgreSQL support in Drupal (yes, I finally got it running!) is definitely behind that of MySQL. In some cases there are error messages with PostgreSQL that don't occur with MySQL. For example, there were problems with password changes because a non-existent field was being accessed. Or in the overview of sources subscribed to in the newsreader there was a message because a non-aggregated field of a complex SELECT was not listed as a grouping field. Or on first access, where no value was specified for the uid field in the sessions table, even though it was declared as NOT NULL. PostgreSQL is definitely more picky than the card file. With PostgreSQL you'll definitely have to modify the PHP code. I'll see - once I'm done, maybe I'll prepare a patch that fixes these issues. So far they're just minor things, but they can certainly be a hurdle for non-programmers. Some of them are certainly based on the somewhat older versions from Debian Stable (for example, the PgSQL API in PHP is named quite differently in newer versions than in 4.1.2).
Wordpress to Drupal Migration Script
Wordpress to Drupal Migration Script - but it currently seems to only be able to migrate from flat file to flat file - you may need to first set up a proper database as the target.
Update: well, the script really only transfers the posts. No post slugs (so no URL preservation), no categories, nothing. You might be able to use it if you only had a very simple WP blog, but otherwise it's pretty bare-bones. And with large blogs it crashes after a while with an error - the available memory is exhausted. This is because PHP uses the CGI settings when run from the command line - and the memory limit is restricted there too. On top of that, it has no duplicate detection, so it cheerfully imports everything again on the second run.
Sounds like I'd probably need to write my own solution if I wanted to try this seriously.
Don't reset existing password on request, prevent DoS password reset abuse | drupal.org
Don't reset existing password on request, prevent DoS password reset abuse - well, I noticed exactly this problem too and couldn't believe that someone actually built something like that into a CMS. In Drupal, you can change the password for a user - any user at all. The new password is then sent to that user by email. So you can't gain illegal access through this, unless you can intercept the user's emails (which shouldn't normally be the case). But you can lock out an admin: simply set up a job that resets the admin's password every minute. And then use this forced absence of the admin to completely spam the Drupal site, for example.
That's really an embarrassing oversight. Unfortunately, it's made far too often and far too frequently. So if you operate Drupal, the patch is recommended (be careful, the author submitted two patches, the first one was still buggy). It installed without any problems and at least fixes the admin lockout. Of course, you still get annoying emails in the process.
Yep, Drupal is going to drive me crazy
Clearly. I don't know what it has against me, but it hates me today. Really massively.
I simply copied the kubrick-theme under my own name so I could customize it without changing the Kubrick-theme itself. Funnily enough, it's now not using the phptemplate-engine anymore. Or more precisely: the entry in the system table (type='theme' and then for the page.tpl.php) doesn't point to phptemplate.engine, but to phptemplate - the .engine is missing. When I add it via update, it works exactly once. After that, this entry in the system table gets overwritten and .engine is gone and the template is broken. Of course, Kubrick doesn't do that. And of course, you can't find any information anywhere about where the heck the theme says which template engine should be used - and how this entry in the system table is created. No, simply grepping for phptemplate.engine doesn't help.
Ok, now it's clear to me that the engine creates the entries - at least after I took a closer look at the engine source. It searches for page.tpl.php and when it finds it, it connects it with the phptemplate.engine. But why would the engine enter its own name incorrectly? Especially since it does it correctly with Kubrick. I just unpacked that into the themes directory.
Alright, so let's keep investigating. A grep -r for INSERT in combination with system then finds the function system_obtain_theme_info in the system.module, where these statements are written. But how and where exactly something is done with it there - sorry, but you can't figure that out without longer study. Somehow the description attribute gets filled with a value that ends with .engine for the Kubrick-theme and doesn't for all others. Kubrick references the theme engine exactly and correctly, but an arbitrarily named copy of Kubrick with identical content references a theme engine without .engine in the name and doesn't work. Great. But renaming Kubrick works. Huh?
Ok, next approach. Rename my template to something else and rename Kubrick to my actually desired name. Complete confusion: my template doesn't work, but the now-kubrick-named one that didn't work before doesn't work either. Uh... So I renamed the Kubrick to something else. And tried my temporarily stored one. That works now. Under a name that isn't Kubrick. Huh? Shell game? Should I just rename the themes around until I eventually have a working one under the name I want and then call it done?
So I tried to resolve the shell game. Computers are deterministic machines after all, that should be possible. Ok, both templates (original Kubrick and my Hugo) renamed. To aa and bb. And which one works? The one called bb. Did the whole thing again, just this time swapped the roles. aa becomes bbb and bb becomes aaa. Which one works now? The one called "bbb". When two phptemplate.engine-based themes are installed in the system, only the last one found in the system at the time themes are being searched works. The others break.
So now I first have to figure out what's wrong with the old themes, why they can't be made to work. First approach: make a database dump and grep to see where all my friends show up. While doing that, I found what's up with the mysterious phptemplate without .engine: the corresponding entries contain a chr(0) instead of the period. Ascii-null. MySQL stores it, but PHP cuts it off on access. And for all the old templates, there are all these broken entries. Also, the engine remembered in the phptemplate extra_templates entry in the variable table which themes it had already seen.
Another clean room test: throw out the entries in the system table with type='theme' and description like 'themes/engine/phptemplate%'. Then it knows nothing more about the themes and their names. Then only have my desired template and activate it. And behold, it works right away. Then unpacked Kubrick. And it works. But after that, my own theme doesn't work anymore. As expected - Kubrick comes after hugo alphabetically. Delete Kubrick again and my own theme works again - after appropriate refresh.
So investigate where the heck this is happening and why. It only happens with the phptemplate.engine themes. The xtemplate.engine themes work without problems. Although it turns out they do it despite the bug - it affects them too. Because in system.module in system_theme_data (how I figured that out I'll spare the readers - it was just successive inserting of echo statements to see when and where things break) it gets destroyed in the last step - in the call to system_obtain_theme_info - on the files the description element. And that's what gets saved in the system table to reference the theme engine. Only the last theme of an engine keeps the correct entry, all others are broken.
Hmm. The basename call on line 336 is the only suspect - it basically only delivers the theme engine without the .engine suffix. But it shouldn't change the actual field, so I hadn't paid much attention to it before - the PHP documentation says nothing about side effects of this function. But when I comment out the entry, my theme works and Kubrick too - simultaneously. But the PHP manual says nothing about basename changing the original string.
So I wrote a small test script that just makes a basename call. Ugh. Yes, that's it - basename changes the original string, and it puts a chr(0) in place of the period. And behold, there's a bug report from 2002 about it - yes, I'm running an old PHP 4.1.2 version, since Debian Stable. The bug report has a workable solution for my problem - just put the variable in "" and work with string interpolation. And behold, problem solved. And make a note to remember: in 4.1.2 basename breaks the source variable.
And a programmer spends debugging time on crap like this (I mean the bug, not Drupal)
I could have learned a decent job. Whisky barrel keeper at Jack Daniels, for example...
Some projects want to drive me insane
or at least that's what one could think. Today's program: Drupal 4.5.2. Nice package, I especially like it because there's now also Kubrick as a theme for Drupal and because it's quite powerful while still being reasonably manageable. But every time I deal with it again after a longer break, I fall into the same pitfalls: for example, enabling translations. It's great that translations exist. But when there's not even the slightest hint on the website about what you need to do, you end up feeling pretty stupid. Ok, yes, you just have to activate the locale.module. But where on earth is that documented? In the x-th hierarchy of the administration menu. Equally annoying: a database connection for PostgreSQL is included. Unfortunately, it's only usable from PHP 4.3 onwards - older versions aren't supported, even though Drupal runs from 4.1. After I've edited everything to use the old function names, it still doesn't work: apparently a default value was missing for the uid column in the sessions table. After I set that, PHP hung when accessing the site. Ok, fine, use MySQL instead (but I don't like MySQL...). Alright, now I'm in, I also have Kubrick as the layout and German translations. Ok, part of the system in German - but there are tons of missing strings. So I know what I'll be doing again soon. Great. Just as great as the default value for the file directory, which is simply "files". Which doesn't work if you want to allow users to upload images, because then "files" and "pictures" get concatenated without a /. And no, the / can't be before "pictures", it has to be after "files". And that with Kubrick the menu in the right column obviously has to be selected as "links" when activating blocks - I probably don't need to mention that separately. And the fact that the manual is anything but up to date - sorry, but that's just ridiculous. It still talks about directory structures in places that don't even exist anymore. No, the settings aren't in sites/default/settings.php - they're in includes/conf.php.
Ugh. This is such a nice project. And the whole system is really powerful and stable. But the documentation is really a joke. Sometimes I get the feeling that people aren't documenting Drupal at all, but something else entirely.
Still, it's nice, so I won't complain too loudly. Others don't really do much better either. Still - it could be so nice if the reference to the online manual would actually help instead of confuse...
Away with Trackback
Isotopp is pondering trackback spam on the occasion of spam day and presents several approaches. One of them uses a counter-check of the trackback URL against the IP of the submitting computer - if the computer has a different IP than the server advertised in the trackback, it would probably be spam. I've written down my own comments on this - and explained why I'd rather be rid of trackback today than tomorrow. Completely. And yes, that's a complete 180-degree turn on my part regarding trackback.
The IP test approach once again comes from the perspective of pure server-based blogs. But there's unfortunately a large heap of trackback-capable software installations that don't need to run (and often don't run) on the server where the blog pages are located - all tools that produce static output, for example. Large installations are Radio Userland blogs. Smaller PyDS blogs. Or also Blosxom variants in offline mode (provided there are now trackback-capable versions - but since they're typical hacker tools, they definitely exist).
Then there are the various tools that aren't trackback-capable, where users then use an external trackback agent to submit trackbacks.
And last but not least, there are also the various Blogger/MetaWeblogAPI clients that submit the trackback themselves because, for example, only MoveableType in the MetaWeblogAPI allows triggering trackbacks, but other APIs don't.
Because of this, the IP approach is either only to be seen as a filter that lets through some of the trackbacks, or it's a prevention of trackbacks from the users mentioned above. And the latter would be extremely unpleasant.
Actually, the problem is quite simple: Trackback is a sick protocol that was stitched together with a hot needle, without the developer giving even a moment's thought to the whole thing. And therefore belongs, in my opinion, on the garbage heap of API history. The fact that I support it here is simply because WordPress implemented it by default. Once the manual moderation effort becomes too high, trackback will be completely removed here.
Sorry, but on the trackback point the MoveableType makers really showed a closeness to Microsoft behavior: pushed through a completely inadequate pseudo-standard via market dominance - without giving even a thought to the security implications. Why do you think RFCs always have a corresponding section on security problems as mandatory? Unfortunately, all the blog developers faithfully followed along (yes, me too - at Python Desktop Server) and now we're stuck with this silly protocol. And its - completely predictable - problems.
Better to develop and push a better alternative now - for example PingBack. With PingBack, it's defined that the page that wants to execute a PingBack to another page must really contain this link there exactly as it is - in the API, two URLs are always transmitted, its own and the foreign URL. The own URL must point to the foreign URL in the source, only then will the foreign server accept the PingBack.
For spammers this is pretty absurd to handle - they would have to rebuild the page before every spam or ensure through appropriate server mechanisms that the spammed weblogs then present a page during testing that contains this link. Of course that's quite doable - but the effort is significantly higher and due to the necessary server technology, this is no longer feasible with foreign open proxies and/or dial-up access.
Because of this, the right approach would simply be to switch the link protocol. Away with Trackback. You can't plug the trackback hole. PS: anyone who looks at my trackback in Isotopp's post will immediately see the second problem with trackback: apart from the huge security problem, the character set support of trackbacks is simply a complete disaster. The original author of the pseudo-standard didn't think for a minute about possible problems here either. And then some people still wonder why TypeKey from the MoveableType people isn't so well accepted - sorry, but people who make such lousy standards won't be getting my login management either ...
WordPress Related Entries plugin
わさび » Archives » WordPress Related Entries plugin - a very nice little plugin that searches for related articles using MySQL's full-text index. Of course, this is only a fairly simple algorithm and the quality of results is nowhere near Google's level, but I installed it anyway. When you go to the detail page of a post (e.g., by clicking on the title), a list of up to 5 matching other articles is displayed.
I also expect this to give somewhat better positioning for various older posts - without having to remember to manually set a link to them every time (hey, most of the time I've forgotten about them myself!). And maybe it will also help people who come via search engines to find what they're looking for.
Besides, it's cool, and cool is good
Caching for PHP Systems
Caching Strategies for PHP-Based Systems
There are basically two ways to implement caching in a PHP-based system. Okay, there are many more, but two main approaches are clearly identifiable. I've compiled what's interesting in this context - especially since some colleagues are currently suffering under high server load. The whole thing is kept general, but for understandable reasons also considers the specific implications for WordPress.
- Caching of pre-compiled PHP pages
- Caching of page output
There are numerous variations for both main approaches. PHP pages themselves exist on web servers as source code - unprocessed and not optimized in any way for the loading process. With complex PHP systems running, parsing and compiling into internal code happens for every PHP file. With systems that have many includes and many class libraries, this can be quite substantial. The first main direction of caching starts at this point: the generated intermediate code is simply stored away. Either in shared memory (memory blocks that are available to many processes of a system collectively) or on the hard disk. There are a number of solutions here - I personally use turck-mmcache. The reason is mainly that it doesn't cache in shared memory but on the disk (which as far as I know the other similar solutions also do) and that there is a Debian package for turck-mmcache. And that I've had relatively few negative experiences with it so far (at least on Debian stable - on Debian testing things are different, where PHP applications crash on you). Since WordPress is based on a larger set of library modules with quite substantial source content, such a cache brings quite a bit to reduce WordPress's baseline load. Since these caches are usually completely transparent - with no visible effects except for the speed improvement - you can also generally enable such a cache.
The second main direction for caching is the intermediate storage of page contents. Here's a special feature: pages are often dynamically generated depending on parameters - and therefore a page doesn't always produce the same output. Just think of mundane things like displaying the username when a user is logged in (and has stored a cookie for it). Page contents can also be different due to HTTP Basic Authentication (the login technique where the popup window for username and password appears). And POST requests (forms that don't send their contents via the URL) also produce output that depends on this data.
Basically, an output cache must consider all these input parameters. A good strategy is often not to cache POST results at all - because error messages etc. would also appear there, which depending on external sources (databases) could produce different outputs even with identical input values. So really only GET requests (URLs with parameters directly in the URL) can be meaningfully cached. However, you must consider both the sent cookies and the sent parameters in the URL. If your own system works with basic authentication, that must also factor into the caching concept.
A second problem is that pages are rarely purely static - even static pages certainly contain elements that you'd prefer to have dynamically. Here you need to make a significant decision: is purely static output enough, or does a mix come in? Furthermore, you still need to decide how page updates should affect things - how does the cache notice that something has changed?
One approach you can pursue is a so-called reverse proxy. You simply put a normal web proxy in front of the web server so that all access to the web server itself is technically routed through this web proxy. The proxy sits directly in front of the web server and is thus mandatory for all users. Since web proxies should already handle the problem of user authentication, parameters, and POST/GET distinction quite well (in the normal application situation for proxies, the problems are the same), this is a very pragmatic solution. Updates are also usually handled quite well by such proxies - and in an emergency, users can persuade the proxy to fetch the contents anew through a forced reload. Unfortunately, this solution only works if you have the server under your own control - and the proxy also consumes additional resources, which means there might not be room for it on the server. It also heavily depends on the application how well it works with proxies - although problems between proxy and application would also occur with normal users and therefore need to be solved anyway.
The second approach is the software itself - ultimately, the software can know exactly when contents are recreated and what needs to be considered for caching. Here there are again two directions of implementation. MovableType, PyDS, Radio Userland, Frontier - these all generate static HTML pages and therefore don't have the problem with server load during page access. The disadvantage is obvious: data changes force the pages to be recreated, which can be annoying on large sites (and led me to switch from PyDS to WordPress).
The second direction is caching from the dynamic application itself: on first access, the output is stored under a cache key. On the next access to the cache key, you simply check whether the output is already available, and if so, it's delivered. The cache key is composed of the GET parameters and the cookies. When database contents change, the corresponding entries in the cache are deleted and thus the pages are recreated on the next access.
WordPress itself has Staticize, a very practical plugin for this purpose. In the current beta, it's already included in the standard scope. This plugin creates a cache entry for pages as described above. And takes parameters and cookies into account - basic authentication isn't used in WordPress anyway. The trick, though, is that Staticize saves the pages as PHP. The cache pages are thus themselves dynamic again. This dynamism can now be used to mark parts of the page with special comments - which allows dynamic function calls to be used again for these parts of the page. The advantage is obvious: while the big efforts for page creation like loading the various library modules and reading from the database are completely done, individual areas of the site can remain dynamic. Of course, the functions for this must be structured so they don't need WordPress's entire library infrastructure - but for example, dynamic counters or displays of currently active users or similar features can thus remain dynamic in the cached pages. Matt Mullenweg uses it, for example, to display a random image from his library even on cached pages. Staticize simply deletes the entire cache when a post is created or changed - very primitive and with many files in the cache it can take a while, but it's very effective and pragmatic.
Which caches should you sensibly deploy and how? With more complex systems, I would always check whether I can deploy a PHP code cache - so turck mCache or Zend Optimizer or phpAccelerator or whatever else there is.
I would personally only activate the application cache itself when it's really necessary due to load - with WordPress you can keep a plugin on hand and only activate it when needed. After all, caches with static page generation have their problems - layout changes only become active after cache deletion, etc.
If you can deploy a reverse proxy and the resources on the machine are sufficient for it, it's certainly always recommended. If only because you then experience the problems yourself that might exist in your own application regarding proxies - and which would also cause trouble to every user behind a web proxy. Especially if you use Zope, for example, there are very good opportunities in Zope to improve the communication with the reverse proxy - a cache manager is available in Zope for this. Other systems also offer good fundamentals for this - but ultimately, any system that produces clean ETag and Last-Modified headers and correctly handles conditional GET (conditional accesses that send which version you already have locally and then only want to see updated contents) should be suitable.
hobix&you!! feel yeah!!
hobix&you!! feel yeah!! is a weblog software written in Ruby. It comes from the author of Why's (Poignant) Guide to Ruby and the project's homepage is accordingly off the wall. You have to give him that: either he's completely out of his mind or he's a genius. Anything in between definitely doesn't fit (found at but she's a girl)
Ian Bickings Wiki - Interesting wiki in Python and Webware based on reStructuredText
Rhizome - Interesting wiki with a focus on semantic content - page references are semantically defined
New image gallery plugin - needs testers - WordPress plugin for images in posts
WordPress Support › Static "like" pages - Discussion about creating pseudo-static pages (e.g. imprint) in WordPress
drupal.org
I'm currently playing around with Drupal a bit. First impression: wow! Extremely powerful, extremely many features. Though possibly too many features. But what I like right away is the very clean interface with quite logical menu structure, and how all extensions automatically hook into these menus. I also like the solution with templates and themes: themes can be divided into templates or stylesheets. This allows you to change the general system, but also just choose variants of a system. The default theme is table-based, but there's another CSS-based one to choose from. I can't really say yet how XHTML compatibility looks. Also good is the support for MySQL and PostgreSQL - I normally prefer the latter. You can also make weblogs with it, as well as static articles, entire books, stories with discussion forums similar to Slashdot or Kuro5hin and much more. However, what stands out right away is that the tools in the individual content areas are somewhat sparse - tools that specifically target weblogs often seem more complete. Specifically things like Trackback, Pingback, update pings or similar have to be installed afterwards or at least reconfigured - the standard only pings drupal.org itself for the distributed login mechanism. Also such elementary things as simple categories (more complex categories - even hierarchical - do exist, but elsewhere) for blog entries require some searching. RSS feeds are automatically created, but on some pages (for example the homepage) they first have to be linked (in user blogs the link is automatic though). Otherwise they are only contained as alternate links, but not necessarily visible to users. Overall, the whole system clearly aims to design and build entire websites with entire groups of users. However, the distributed login mechanism is really cool: users from participating systems can log into other participating systems with user@host and the login is automatically passed to the home system. Login with always the same password, but with distributed authorization. Very nice! Overall, a lot of value is placed on user management - it almost has Zope dimensions with its permission groups and the ability to create symbolic permission groups for individual activities. Less cool are the many missing metadata. There's actually hardly any metadata on content. Author, date, status - but that's more or less it (of course besides title and text, those are self-evident). Content organization is also left to the user - though there are helper tools that make creating navigation easier. However, many metadata topics (such as categories) can apparently be solved using taxonomies - these are groupings of content. The description of this is somewhat unintuitive, the topic is quite complex. Taxonomies are groupings of keywords on a topic. So I don't assign posts to categories, but rather assign keywords to posts and then organize the keywords into categories. While this provides mountains of metadata, it's far more complex than the normal blog categories you're used to.
Great again are all the content status and content versioning functionalities. All changes are logged. All changes to content are versioned. You can go back to older content and thus, for example, fix errors (or remove garbage from rogue users).
The whole system is extensible, but I suspect (haven't checked it yet, but given the range of functionality it's a likely guess) that creating plugins and filters is more involved than with small solutions like WordPress. But that's in the nature of things.
Another potential disadvantage is the unavailability of a ready-made German translation. While there are other sites working with Drupal in German, apparently no one releases the complete translation tables for download - at least I haven't found anything, neither at drupal.org itself nor on Google.
Where would I classify Drupal? Clearly in the CMS category - that's where systems like Typo3, Mambo Open Source, Plone and similar systems shine. However, it beats discussion-oriented CMSs like Scoop or Squishdot by a mile - as well as simple blog CMSs. For a simple blog system it's clearly overkill. For a complete site it seems very usable.
Releases | drupal.org - Download page for Drupal modules
Daring Fireball: Markdown Syntax Documentation - Interesting text conversion to XHTML for PHP and Perl - similar to reStructured Text
b2evolution: Home
b2evolution also makes a good impression on paper. It's surprising how far all these blog programs have come while you're not looking.
In any case, b2evolution makes a very good showing when it comes to antispam and security. And it also seems to have good XHTML support and a plugin architecture. The plugins are divided by purpose (Edit-Plugins and Toolbar-Plugins). I think the somewhat simpler form of plugins in WordPress will be easier for many to understand, but programmers will probably prefer b2evolution.
Personally, the admin environment is a bit too playful for me - though I only looked at it in the online demo. Also, the standard template doesn't look as clean and tidy as WordPress's - I think with the latter you have an easier start to impose your own layout. What's definitely nice is the choice of input parser for posts - I've done something like that in the Python Desktop Server too, precisely because you don't always want to have certain plugins active. Otherwise, it's of course very similar to WordPress - it's also a b2 descendant. WordPress probably has better support for images since it can automatically create thumbnails. Also, b2evolution lacks the metaWeblogAPI. On the other hand, what's nice is the integration of referrers and search engines directly into the blog - similar to the evaluation that the Python Community Server does for me. The usability design of b2evolution seems a bit confusing in places: permalinks to posts are small chain symbols, permalinks to comments are small document symbols. It's also somewhat inconsistent in other places.
Conclusion? If I can draw one at all from this mini-test, I'd say that for me, b2evolution implements just one small checkbox, switch, or option too many for most features. Therefore, I would personally lean more towards WordPress - I can imagine the code is somewhat simpler in structure and therefore custom hacks can be integrated more easily.
In terms of function, however, b2evolution clearly wins on points. Whoever prefers lots of features and likes to draw from a full well, or who wants to venture beyond normal blogs more strongly into the CMS area, will certainly be thrilled with b2evolution.
What I don't understand with either b2evolution or WordPress: neither of the two projects implements stories. That is, article formats that are not fixed to the calendar. Sure, you can realize that with a category or with a separate blog (with b2evolution's multiblogs functionality certainly much easier than the category hack needed for WordPress), but I find it impractical that you have to go to such lengths just for an imprint...
WordPress Wiki - Comment Moderation Plugin - Comment confirmation via email - could be interesting for TIMMY
WordPress Wiki - WP Plugins - WordPress Plugins for the new 1.2 Plugin Interface
Mambo at the Yard - Mamblog Homepage - Blogs for Mambo Open Source
MamboOS Documentation : Home Page - Documentation server for Mambo Open Source
Mamboportal.com - Mambo Open Source CMS Portal - Mambo Open Source Modules and Languages
MOS - Homepage of Mambo - Open Source CMS
yops.de ::: what are you waiting for? - More downloads for Mambo Open Source (e.g. file manager)