Peter Wilson walks us through making sure print stylesheets are loaded after the rest of the page is loaded, so they don’t hold up page rendering.
Pardon my ignorance here, but Rasmus starts talking about latency and concurrent requests about 16:30. He then mentions “one line of code” installation of something that sounds like “aqua code cache” that gives WordPress a 3x performance boost in response time / number of transactions per second. Anyone knows what he’s talking about there, shoot a note and I’ll update this permalink with the info. He goes on to talk about much more hardcore-PHP-nerd WordPress optimization stuff.
The scoop via Joost Schuur:
Rasmus is talking about an ‘opcode cache’. It essentially caches the parsed PHP scripts in memory. That means PHP doesn’t have to read it from disk or even convert the humanly readable PHP script code into executable machine code (opcode). The one he’s referring to is APC, which is likely going to be included in the next big release of PHP. Xcache is another popular kind. I run it on my site and got about a 3x performance increase on page request server times, so the numbers add up. The W3 Total Cache WordPress plugin has the option of using Xache or APC to keep popular pages in memory via opcode caching.
Just a reminder that WordPress version 3.0.1 is available, so take a few moments and update your website. Staying current is one of the best ways to keep things running smooth, safe and secure. The new version addresses about 50 minor issues and helps to make WordPress 3.0 even better.
Amazingly, WordPress 3.0 was downloaded nearly 11 million times in 42 days. So HUGE congrats and thanks to the entire WordPress crew for an amazing piece of software.
We use E-Junkie ourselves on this site to sell the book. This plugin brings to two together to theoretically make that process easier.
This looks awesome: “The WPAlchemy MetaBox PHP Class can be used to create WordPress meta boxes quickly. It will give you the flexibility you need as a developer, allowing you to quickly build custom meta boxes for your themes and plugins.”
The discussion starter post last week about WordPress theme frameworks worked nicely. I really enjoyed the comment thread that took place so I thought I’d point it back out to people who may have missed that or didn’t see it fully developed. Specific thanks to Justin Tadlock and Nathan Rice for sharing their thoughts as authors of popular frameworks.
I was on the WordPress Podcast with Joost De Valk talking about a whole bunch of things including WordPress 3.0 which was freshly out.
I did a screencast where I took a site that was working on localhost and moved it up to a live domain name. This involved moving the files, moving the database, and altering some information in the database. This is a good thing to know how to do if you are just getting into WordPress development. It is also just as relevant in moving a WordPress site from one domain to a different domain.
Here are a few specific circumstances where elmalak feels that Jooma is better than WordPress. I understand some, disagree with others. I’m always interested in debates comparing different CMSs, but have never read anything that really nailed it. Largely I think people defend the one that they use the most and the one they feel most productive using. Hey, that’s what I do.
Update: 404 link removed:
In-depth overview from Paul Kaiser on how WordPress 3.0 is expanding and improving upon creating custom taxonomies, including how they can now be hierarchical. Most importantly Paul shows how (and why) they can be used in themes.
Anything you create in the global namespace has the potential to conflict with a theme, another plugin (including one you wrote), and WordPress core itself. Thus, prefix everything with a unique-enough character set. For example, all functions I write always start with “nacin_”, and I make sure that my functions are unique across all of my plugins.
In this recent post, I used some fairly generic function names like
custom_css_hooks. Andrew is saying that names like that are a little too generic and that it’s possible another plugin could use that same name which would be rather disastrous. Since it’s totally internal anyway, I should have called it
digwp_custom_css_hooks, which would be far less likely to meet a conflict.