Community Blogs

I have another How To Joomla article up: How to debug our Joomla code with FirePHP. Just recently, I discovered a plugin that painlessly adds FirePHP to your Joomla site. After installing it and doing some tests, I decided to write an article. In the midst of writing the article, I went to the FirePHP wiki and found another FirePHP plugin for Joomla released by the Kunena team. This one is even better, with tighter integration into the Joomla environment. I see many possibilities for model debugging and exception handling down the road.

Drupal and Wordpress also have FirePHP plugins, as do most of the major stand-alone PHP frameworks. Have a look to see if your favorite is listed before trying to hack FirePHP into your next project.

A lively little discussion developed over the past few days on the DC-PHP developers mailing list. We have a very active developers group here in the DC area – much larger than most cities, in fact. Part of what makes our group great is the diversity of background and experience that is in the group.

This was front and center over the past few days when one of our members, Hans, offered his opinions on Facebook’s new HipHop for PHP product. We have already expressed our intent to help make WordPress compliant with HipHop, something that will be beneficial to major WordPress sites like TechCrunch, Mashable, VentureBeat, WordPress.com, the NFL Blogs, the NY Times blogs, the Cheezeburger network (LOLcats, FAILBlog, etc) that carry large amounts of traffic. I hope to be able to consult with some of these organizations on moving into a HipHop system once my head is wrapped around it and WordPress is compliant.

Photo by Josh Hunter

Hans is an extraordinary developer. I have never met him personally, but his depth of knowledge on issues of security and scalability is downright frightening. He offered his own opinion of HipHop on the mailing list and so I’m going to pick on him a bit:

This HipHop thing is interesting, perhaps in much the same way as HipHop music: it feels like a hack. — And I mean that respectfully in both cases; I like hip-hop music, and appreciate how it pays homage to R&B roots, remixing/reinterpreting them, etc; and I think that the idea of taking one language and building it out to something else is also something I should support. After all, I’ve embroiled myself in code generation tools (e.g. Propel) that are operating on the same philosophical groundwork. But I also believe that there’s a general rule like “if you need code generation, there’s something wrong [in your design or in the tools you've chosen or ...]” … so those tools also feel like hacks.

In all of life, there is an evolution that happens. One iteration of something becomes better with improvements over time. This has happened on a micro level inside PHP. Without PHP 3 there would be no PHP 4. Without PHP 4, there would be no PHP 5. Ben Ramsey talked about this evolution before Christmas.

Why is it a hack to improve upon the tools used with a language? Is it a hack to use Memcached with PHP? Is it a hack to run on nginx instead of Apache or to implement FastCGI? All of these are third party software or extensions outside of PHP. So how is HipHop any different?

That’s all fair, but I feel like the problem here is that somewhere a long, long time ago, Facebook *must* have realized that they were going to have scaling problems. Long before they started having a problem, someone *must* have thought “maybe a compile-at-runtime language isn’t the right solution here”. I guess to me this cross-compiler is just a public way to admit that PHP is not the right tool for the job, but they’re stuck with all these developers that only know PHP so it was somehow cheaper to engineer a way to change PHP to C++ than it was to retrain developers on C++ (or, probably more realistic, Java).

I responded in that conversation with an only slightly edited response. While I appreciate, and always have appreciated, his frank, honest, high level view of PHP, web security, web applications, etc., he strikes me as somewhat naive and puritanical.

What I can say is *I*, along with dozens of other technology people in and out of DC, in and out of PHP, never look at our initial ideas as scaling ideas. We look at them as ideas and experiments to see if they have legs. In fact, I’d go so far as to say it is counter-productive to think about scale before thinking of concievability (is that a word?).

There’s a reason why Rails (God help us) is popular. It’s a great prototyping tool. You stand up an app quickly and let it into the wild to see if it has legs. Does it go? What are the market influences? What are the
pros and cons? Do we have to adjust?

After a concept is proven, then a solid dev team with solid tech leadership brings in their expertise to see if the idea can be built into something sustainable. As a sidebar, please take a read of Brad Feld’s very awesome
post from a few years ago “The first 25,000 Users are Irrelevant“.

My point is, it’s silly and a waste of resources for startup people to start thinking about how big they might get maybe 5 years down the road. I think you’d find out that, in most cases, successful technology, web-based companies happened by some dumb luck. Twitter. Facebook. Name-the-popular-app. Dumb luck.

Hey, I’d even argue that when too much comp-sci brain energy goes into an app, you get things like Wolfram Alpha. Cool. But useless. And not nimble enough to actually do the scaling necessary to need all that comp-sci engineering prowess.

Balance, my friend. Balance.

Facebook (and others) start with PHP because PHP is fairly ubiquitous and easy as pie to drop into production. However, there is a point of no return where you are committed to PHP and that’s where HipHop comes in.

Personally, I wish we had HipHop when I was at b5media. We had a ton of scaling problems with PHP and we were running fully clustered Apache servers (25 deep, if I recall), sharded MySQL across 6ish database servers, and we had massive I/O bottlenecks. We ran eAccelerator and Memcached and had squid-based load balancing and damn if Grey’s Anatomy or the Oscar’s didn’t pin our entire network on more than one occasion. What could have happened with an alternate to opcode caching. What could have happened if I had resources to put on developing C++ binaries of our frequently used PHP libraries.

I’ll tell you. It would have rocked. We were already committed to PHP. We were already committed to WordPress. And when the company started, we were all volunteer resources. There was no assumption that our idea had legs or I think everyone on the team would have quit our jobs immediately and put everything into building that company. It took a year to get there.

This is, for better or for worse, the way companies get started in the real world.

Written by Aaron Brazell on February 4, 2010

addthis_url = 'http%3A%2F%2Ftechnosailor.com%2F2010%2F02%2F04%2Fhiphop-php-and-the-evolution-of-language%2F'; addthis_title = 'HipHop%2C+PHP%2C+and+the+Evolution+of+Language'; addthis_pub = 'technosailor';

Earlier this week, I made my debut on HowToJoomla.net with an article on How to Fix Joomla Content Plugins. If you’ve used Joomla since the 1.0 days, you may recall that content plugins acted on both articles and Custom HTML modules. In 1.5, this behavior changed so that Content plugins only act on articles from the Article Manager. Fortunately, there are several options for regaining and controlling this functionality, which I outline in the post. Head over and let me know what you think!

When I originally received my copy of the Joomla! 1.5 Development Cookbook, I was in the middle of a large client project. The book sat over on my shelf for a few days waiting to be read. While working on my code, I came to a point where I wanted to add some custom markup to the portion of the HTML document. Although I usually whip out my Joomla Textmate bundle to pull up the right snippet, this wasn’t something I already had preprogrammed and ready to go.

If I learned something, you’ll learn something

I was about to do a Google search, but suddenly remembered that James’ book was in arm’s reach and might have the answer. After turning to the index and finding the topic, I quickly located the exact code I needed to move on. Despite having written a book on Joomla myself, this one came to my rescue at just the right time!

While it took me a while to read all 130 recipes (including time on airplanes, buses, and sitting in my living room), the practical tips and methods were worth it. James covers a wide breadth of Joomla programming topics, matched only by his Joomla Framework reference. Most passages are 2-3 pages long and include relevant information that’s quickly applicable to any Joomla project you’re working on.

Essential information

Two chapters in this book really make it a must-purchase for any Joomla developer. The Multilingual Recipes chapter gives more in-depth information on internationalization and character encodings than any other Joomla reference I’ve seen. Even if you’re only creating a website in one language, it’s imperative that you understand how character encodings work. Current versions of PHP have some shortcomings with handling UTF-8 strings, but Joomla’s special libraries will help you handle them correctly.

Character encodings aside, Keeping it Extensible and Modular is the most useful chapter in the entire book. This chapter is devoted to helping you work with Joomla’s different extension types and getting around some of the shortcomings in 1.5. For instance, James shows you how to create installable libraries by creating a custom type of plugin.

Also, this chapter has a recipe for using the component installation process to install additional extensions. This method allows you to include your modules and plugins inside of your component package; installing multiple extensions in one click. I plan on using it as soon as I get a chance to work on the Podcast Suite!

While the content in this book is very strong, it does have a couple of drawbacks. While most of the recipes have readily usable code that’s straightforward, a few of them don’t make a strong case for why you would use the described method. For instance, there’s a recipe on creating and raising a custom error level. It goes into how you want to avoid conflicting with Joomla and PHP error codes, but it doesn’t explain why you would want to create a custom error level in the first place. Fortunately, most of the recipes have more context.

I’m willing to read more than two pages… seriously.

The biggest disappointment of this book is in the execution of the cookbook format. Having read other “programming cookbooks” in the past, I know that the goal of these kinds of books is to help you find relevant information on specific topics quickly. However, Packt seems to have decided that providing “quick information” means catering to readers with severe cases of attention deficit disorder.

If you try to read entire chapters of this book at a time, you’ll notice that some recipes are almost identical. In Chapter 7, there are individual recipes on setting the HTML document generator, description, and metadata. These add up to less than three pages, but all include the same introduction at the beginning of each. Additionally, all three of these include “See also” references to each other. These would have worked much better as a combined recipe, including a reasonable scenario where you would want to set these things. In its current form, almost half of your reading consists of headers and duplicated information.

I get the feeling that Packt was trying to break all of the topics up into the tiniest pieces possible. This way, they’re able to slap “130 simple but incredibly useful recipes” on the cover and advertise a page count of over 300. This is really taking a short view of things, as James did a wonderful job with the topics he covered. While some marketer is probably pushing for a specific length, I’ve found that the length of a book is not proportional to its usefulness. For instance, I learned far more in 145 pages of Javascript: The Good Parts than I did in nearly 800 pages of Programming Ruby.

Hidden Joomla treasures

Despite the sometimes choppy format, the Joomla! 1.5 Development Cookbook organizes a lot of how-tos missing from Joomla’s online documentation. Anyone coding anything more than the simplest module can benefit from the recipes in this book. James demonstrates expert programming knowledge and delivers it in a very accessible format. The time you’ll save by having this information at hand will offset the cost of purchasing it within the first week. If you’re writing code for Joomla, you need this book.

UPDATE: you can also read a PDF sample of Chapter 2 from Packt’s website.

This was originally posted on my company blog and reposted here for posterity.

By now, the news has hit the street about Facebook’s new PHP pseudo-compiler technology that is looking set to change the PHP world once again. It is called HipHop for PHP.

Here at Emmense, we build on PHP and more specifically, we build on WordPress. The PHP community as a whole continues to innovate the language and Facebook has been a longstanding member of that community. WordPress stands on the shoulders who have gone before, and there are certainly instances of large-scale installs of WordPress that could stand to use some acceration.

It is our intention, here at Emmense, to support the Facebook HipHop methodology where appropriate. We will be exploring the use and implementation of this technology in the days and weeks to come and will be working to build solutions that leverage it in the WordPress world for our clients. Where possible, our work will be conributed back to the WordPress core where appropriate.

While we expect that many more service providers will likely leverage this technology, we want to continue to lead in the WordPress community in an ever-open exchange of ideas between the PHP and WordPress communities.

Written by Aaron Brazell on February 2, 2010

addthis_url = 'http%3A%2F%2Ftechnosailor.com%2F2010%2F02%2F02%2Ffacebooks-hiphop-and-what-it-means-to-wordpress%2F'; addthis_title = 'Facebook%26%238217%3Bs+HipHop+and+What+it+Means+to+WordPress'; addthis_pub = 'technosailor';

Late last month, I received some bad news about web2project...

It turns out that web2project was vulnerable to a handful of select Cross Site Scripting (XSS: definition) vulnerabilities. While the attack vector was pretty specific to being an already authenticated user, it had the potential to be a major problem in a poorly configured system.

On the positive side, I say "was" because within 10 days of being notified of the problem - and the same day the vulnerability became public - we had a patched release out the door and available to users. We've spent the past month since encouraging them to upgrade. Of course, we further benefit from the fact that although the vulnerability does affect us, we're not named in the report.

On the negative side, it did take us 10 days to close the vulnerability. The patch itself was available a few days earlier via Subversion but it might not have been enough. Further, we didn't explicitly notify our users of a need to upgrade but since it was rolled with a handful of other major fixes, it appears that many people have upgraded already. Once again, we benefit from the very specific attack vector.

To make this process easier and faster in the future, as of v1.3, we can already detect if upgrades have been uploaded but not applied. For an upcoming release, we're implementing a Drupal/WordPress-style means of notifying existing administrators thatan upgrade is available. In the meantime, watch this space or web2project's page on Sourceforge.

Recently, I realized that despite talking about Karl Fogel's book - "Producing Open Source Software" - numerous times over the past year[1][2][3], I've never written a review of it. So without further ado, here we go.

I originally picked up my copy in mid-2007. It took me a couple months to get to it, but once I did, it rocked my professional world. To be clear, Karl Fogel is an early (founding?) member of the Subversion Version Control System.

Karl starts off talking about the beginning an Open Source project and the things - both community and technical - that are required to get things rolling. If you're participated in an even moderately active/successful open source project, none of this will be surprising, but having all of it enumerated clearly never hurts. If you go with something like SourceForge, Google Code, Launchpad, or Microsoft's CodePlex, you'll have version control, forums, some release management and bug tracking immediately. Honestly, getting the technical infrastructure setup is just plain simple.

The more important portion to me was the other "half" of the book where he discusses the team dynamics side of things.

First of all, he talks about basic Political and Social Structure of the team itself. While he lays out some general principles, the more important and valuable stuff is in his specifics. How are important decisions made? How do community members become team members? What roles and responsibilities does a team member have over a random community member?

Next, in Communications, he talks about all the day to day things we have to deal with. Difficult users, the proper tone, how to diffuse arguments, and generally how to keep things on topic are all covered. Does it all work? Nope, not all the time. But some of it definitely might work some of the time. Regardless, it's a good overview of tips and tactics interspersed with real world examples from the Subversion project.

Finally, there is detailed discussion of Managing Volunteers. This is where the vast majority of projects have problems and the reason is obvious. Very few developers - no matter how sharp they are - know how to motivate people, engage a community, and delegate tasks. Most of us confuse communications and evangelism with marketing... which realistically, I guess they are the same. Doh.

This was highlighted for me last fall at ZendCon when one person asked a panel "Do you think it's appropriate for a project to ask their users to go vote in [technical] polls?" If a project's leadership isn't supposed to engage and occasionally direct their community towards goals complementary with the project, I'm not sure what the point is.

So overall, almost every single idea struck me as both blindly obvious, incredibly powerful, and almost always missed. And the single best part about this entire book... about 90% of it applies to any project or technical community. Yes, I don't care if you're working on an Open Source project, an internal project, or a commercial shrink-wrapped application. You can use almost any idea from this book and apply it immediately.

When I started reading this book, I was active in DCPHP, working with a startup, and on the verge of leaving dotProject. This book crystallized many of my concerns and thoughts about what a community and project could and should be, so I set out to take the best ideas from the book and apply them to each of the communities that I participate in. It's been one of my primary motivators in unconference organizing and web2project and I don't hesitate to recommend this one to anyone who needs to make their project successful.

Overall, I give it a 10.

By the way, all of "Producing Open Source Software" is available under a Creative Commons license at ProducingOSS.com.

Panels is one of those Drupal modules that engenders a range of feelings around here.  Some people love it -- interface configurable layout! -- and some hate it -- difficult to manage .5em gutters.  But it, and Chaos Tools which it is based on, provide a great deal of useful functionality.  The problem is there is very little documentation on how to extend it beyond what's distributed in code.  The basics of extending Panels/CTools is pretty easy, you just implement the hook_ctools_plugin_directory to tell it where to look for your files, e.g.

function MODULE_ctools_plugin_directory($module, $plugin) { if ($module == 'ctools' && !empty($plugin)) { return 'plugins/' . $plugin; } }

This presupposes you have a directory under your module named 'plugins.'  Inside that directory you can have various other directories corresponding to additional extensions, namely 'access,' 'arguments,' 'content_types,' 'contexts' and 'relationships.'  As you might expect 'access' contains access extensions, 'arguments' contains arguments, 'contexts' contain CTools contexts, 'relationships' contains relationships and 'content_types' contains outputs that can be placed into panes. They all follow the same sort of pattern, there is an initial hook that is composed something like MODULE_CONTEXT_ctools_contexts (e.g. for a module called foo which exposes a context called Bar it would be foo_bar_ctools_contexts) which returns an array with various configuration options. 

Content types tend to be very helpful because you can write custom outputs and they can be knowledgable about CTools contexts (nodes, taxonomy terms, users, etc.) and you can be quaranteed that those contexts will be passed in and not have to worry about testing for them.  To create a custom content_type you would have your directory set up like the following:

module / plugins / content_types / foo / bar.inc

And in bar.inc you'd have the following:

/** * Callback function to supply a list of content types. */ function module_bar_ctools_content_types() { return array( 'single' => TRUE, 'title' => t('Bar output'), 'icon' => 'icon_node.png', 'description' => t('The bar of the foo.'), 'required context' => new ctools_context_required(t('Node'), 'node'), 'category' => t('Node'), ); } /** * Render the custom content type. */ function module_bar_content_type_render($subtype, $conf, $panel_args, $context) { // If we don't have a context return no value if (empty($context) || empty($context->data)) { return; } // Build the content type block. $block = new stdClass(); $block->module = 'bar'; $block->title = t('My title'); $block->content = 'I can put anything here'; $block->delta = $node->nid; return $block; } /** * Returns an edit form for custom type settings. */ function module_bar_content_type_edit_form(&$form, &$form_state) { // provide a blank form so we have a place to have context setting. } /** * Returns the administrative title for a type. */ function module_bar_content_type_admin_title($subtype, $conf, $context) { return t('"@s" bar', array('@s' => $context->identifier)); }

This is a pretty simple example, but it has most of the required hooks to make a new content_type.  The first hook,  module_bar_ctools_content_types, returns the content_type definition; basically the title and description, whether it requires a context to be present and of what type (the example above requires that the CTools page has a node context either from an argument or fixed context) and which tab it should appear in; in this case the 'Node' tab.

If you require a context you need a configuration screen in order to set which context(s) to pass to the content_type.  The module_bar_content_type_edit_form hook tells CTools that we need a configuration form which will contain settings for the contexts to send to the content_type.  Since we aren't using anything other than the context no other form elements are required.  If you wanted other configuration this function would return a Drupal form array to be rendered.  If there were additional configuration you would also implement the _validate and _submit hooks, so you'd have module_bar_content_type_edit_form_validate and module_bar_content_type_edit_form_submit following the normal Drupal form submission rules.  The data for the content_type configuration is stored in $form_state['conf'] which is stored by CTools and put into the $conf variable for the _render hook.

That brings us to module_bar_content_type_render.  The variables passed in are pretty straightforward, $conf is any configuration exposed by module_bar_content_type_edit_form, $panel_args is an array of arguments parsed by the Page, and $context is the CTools context that is passed to the content_type (i.e. the node, user, term, etc.).  From there the return looks like an object form of the typicaly block output. 

 

Forum One's tech department has evolved into primarily a Drupal shop. Drupal is a great fit for a lot of our clients, and the majority of our technology solutions involve molding Drupal to fit with our project needs.

Every successful development firm has learned to adapt quickly to changes in their environment. While Drupal is pretty robust, it's not the right tool for every job. In the past, we as a team have used tools such as SyntaxCMS, CodeIgniter, Zend Framework, and WordPress to get the job done. This kind of technical diversity is essential for any development shop.

Every once in a while, I come across a tool or service that seems to stand out. Enter Firerift.

Firerift is a Content Management Tool, just like Drupal or WordPress. It was first released in August 2009, and is built on top of CodeIgniter. What seems really cool to me is that it's mainly a UI layer on top of a JSON API. This means that practically any data on the site can be retrieved via a REST API call (and this API can be set as public or private).

Another interesting feature is its seamlessness with design. It supports a CSS data layer, where you give your HTML elements specific CSS classes, and Firerift uses jQuery to stick content into those classes. Within the class attribute, you can also specify things such as order (opt_random) or limit (opt_limit_5). While this may not be the most efficient approach, and while the list of CSS options seems a bit scarce, it's still something totally unique.

The fact that all the database information is accessible in raw form seems like a really innovative approach. This holds especially true for government clients (such as the Census Bureau), where data openness is strongly encouraged.

Firerift is JavaScript-heavy, and JavaScript must be enabled for it to work. Also, the code is closed-source (and it costs $49 per top-level domain) -- which may put a damper on the number of contributed extensions. Lastly, Firerift is AJAX-heavy and, therefore not very SEO-friendly. Take this into consideration before proposing as a solution to SEO-conscious clients.

Since the v1.2 release in early December, it's been a bit of an adventure... in the first week after the release, we got a couple major bug reports. Another few days resulted in a few more. Another day, another bug. In the first two weeks, we received a total of 7 bugs that ranked from major to critical. All in all, it was a bad time. Conveniently enough, none of the bugs were particularly complicated or deep, so we were able to quickly resolve each of them and eventually release a v1.2.1. And after receiving word of a small issue requiring another merge, v1.2.2 shortly after the New Year.

While a few members of our community were understandably upset, I was impressed that the bugs were found so quickly and resolves just as quickly. I couldn't put words to this well until I read Karl Fogel's post "Bug Growth is Proportional to User Growth, and Bugs are not Technical Debt." Wow, that Karl is a smart guy. More on that topic later.

For v1.3 we have quite a few features and fixes on the way:

First, we've written some Views Helpers. These helpers handle auto-linking fields that have url's in them or even email fields. On the other side of things, we've added validation for email and url fields. If something is supposed to be a url, it will be.

Next, we've moved the Upgrader into the System Admin. By doing this, we can make sure only Administrators can upgrade a system. Further, we've added a warning message in case someone deployed an upgrade but didn't run the script.

Next, we've added CSS "minification". Through some creative manipulation of our Phing script, when our download package is created, it compresses the CSS. We were able to trim 33% from both the download packages and the installed application. We've tracked down a few other places and can probably drop another 20-30% of the package the same way.

Finally, we're spending quite a bit of effort on character encoding and internationalization. If you use web2project exclusively in English, you haven't noticed any problems. If you use German, Russian, or a variety of other languages, you've noticed issues in the Gantt charts and the PDFs. Unfortunately, to resolve this one, it takes a lot of effort:

• At present, the Gantt charts are created in three different places in the system with similar-but-not-quite-the-same behavior in each. This is being resolved with the GanttRenderer class but it's not all there yet. The added benefit is that now the jpGraph component is abstracted away from the core code. We've talked about replacing it but now we really can.
• Even worse is the PDF generation. Each report of the Reports module handles its own PDF generation, file creation, and even naming conventions. We've started refactoring this to handle it all in our CReports class. It hasn't simplified much but it's already allowed us to make the report generation and cleanup a little more secure.

On a related note, we've also been working on compatibility. v1.2 was the first version of web2project to formally support IIS7 but v1.3 is going to push this even further in at least one major direction.

Stay tuned...

Both of the lifestreaming projects discussed in this Ars article are both built using PHP frameworks, one Zend and the other is CodeIgniter.  I was pleasantly surprised, I expected them to be Python or Rails projects.

In days of yore, all a self-respecting Internet enthusiast needed to be at the forefront of Web hipness was a simple vanity page with pictures of their dog and maybe a few moderately coherent rants about technology or politics. In the modern world of Web 2.0, where our thoughts and activities are strewn across the global network of tubes, we need slightly more sophisticated solutions to capture and convey the ethos of our Internet identities.

Make your own lifestream with open source Storytlr

This is a quick guide on how to translate your WordPress site using a POT file and tools involved in the process.

What framework is used for translating WP?

Using the gettext translation framework, there are three files involved in translating your wordpress site.

• POT (Portable Object Template) File
  Using a program to search through your WordPress code for any text enclosed within a __e() or __() function will a POT file be generated. Within this file you will find the text available for translating. This file you will provide to your translator(s) to translate and return to you.
   
• PO (Portable Object) File
  After you have received the translations you can then place them within the POT file and save your file as a PO file.
   
• MO File
  The final step in the localization process is that the PO file is ran through a program that turns it into an optimized machine-readable binary file (MO file). Compiling the translations to machine code makes the localized program much faster in retrieving the translations while it is running.

Using poEdit to translate POT files

poEdit is an open source program for Windows, Mac OS X and UNIX/Linux which provides an easy-to-use GUI for editing PO and generating MO files.

Getting Started with poEdit

1. Download and install poEdit
2. Download the official WordPress POT file
3. The poEdit screen
4. Open the file in poEdit.(See Image) The box labeled(1) is the original message (in English) from the POT file. The box labeled (2) is where you add your translation. Boxes labeled (3) and (4) are used for adding comments about the messages. These come in handy if you are working with a team of translators and would like to pass around ideas through the PO file. Go to File → Save as… to save your translations in a PO file.When you are finished translating, go to File → Save as… again to generate the MO file.Or you can set your poEdit to always compile a MO file when saving changes by clicking File → Preferences and on the Editor tab check the Automatically compile .mo file on save box.

Configuring your site to use your translation files.

Now that you have your translation files prepared and ready for use you need to tell your site to use them.

Open and edit your wp-config.php file.

Set the global variable, WPLANG with the abbreviated name of the translation.

define ('WPLANG', 'language');

Where to place your translation files Site wide translation (core wordpress code)

For text and phrases used within the core code of WordPress.

/wp-content/languages/language_COUNTRY.po
/wp-content/languates/language_COUNTRY.mo

Theme specific translation (theme specific)

For text and phrases used within themes and includes a domain within the __e() and __() functions.

Example: __e('Comment','theme_specific_domain') or __('Comment','theme_specific_domain')

/wp-content/themes/theme_directory/language_COUNTRY.po
/wp-content/themes/theme_directory/language_COUNTRY.mo

Translating Themes

Considering that themes have their own design and are custom there is a pretty good chance that there is some text that is unique to that theme and not included within the core code. For that reason, a separate or additional translation file is needed tailored to the theme (domain of the theme). Both translation functions, __e() and __() have a domain parameter which can be used to tell wordpress which translation files to use.

Configuring your theme to use its own translation files

Edit your functions.php file located within your active theme directory (/wp-content/themes/theme_directory/functions.php) and add the following before K2::init();

load_theme_textdomain('theme_domain');

K2::init();

If your domain is 'theme_domain' then your translation functions within your theme files will look similar to the following examples:

__e('Comment', 'theme_domain');
__('Comment','theme_domain');

 

It is good practice for theme developers to include a POT file with the theme files. In the event that you do not have a provided POT for your theme of choice you can use poEdit to scan the theme files and to generate a POT file. For instructions on how to configure poEdit to generate POT files visit http://scratch.wik.is/Translation/Translating_scratch.mit.edu/Creating_POT-Files.

After following the above steps you should now be able to reload your site with the new translations. 

 

Sources:

• http://codex.wordpress.org/Translating_WordPress
• http://urbangiraffe.com/articles/translating-wordpress-themes-and-plugins/
• http://scratch.wik.is/Translation/Translating_scratch.mit.edu/Creating_P...

 

Twas the night before Christmas and all through the house,
Not a peripheral was stirring, not even my mouse.

I with my Xbox and wife with the same
had just settled down to a nice co-op game.
I covered the front, she took the rear
our enemies had a dynamic duo to fear.

At a loud crash, I arose from the chair
wondering "what could be happening down there?"
We entered the room and what did we see,
but two surprised cats and a sad Christmas tree.

"But wait, what is that in the paws of the kitten?"
Something unexpected, something unbidden.
A gift certificate for Amazon, another for Fry's,
both looked like glittering gold in my geek eyes.

My imagination went wild, it just wouldn't stop,
so many ideas, my head might just pop.
But then I wondered "from where did this appear?"
and the wife agreed "this wasn't just here."

I scanned the room and looked for the source,
everything was in order as a matter of course.
Everthing was in place, right where it belonged.
But wait.. that's not right.. that's entirely wrong.

The books were all sorted according to writer,
even the whiteboard was a little bit whiter.
The cables were untangled and sorted with care,
I couldn't move, I stood there and stared.

This didn't make sense, how could it be?
Is this a big joke, is someone messing with me?
I checked my computer but it was fine.
I still had ten bugs waiting.. No, now nine.

Then eight then seven then six, now five,
what is happening is this thing alive?
Another minute and what did I see
but twenty-eight commits in the source tree.

I looked at the code and something was wrong,
I knew my coming nights would be way too long.
The code was small and fast but I wanted to hurl,
the whole damned thing was written in Perl.

If you're looking to build your own style plugins for Drupal's Panels module, the following post will step you through how to do so. The functions and files you'll need to declare are a bit arcane and this beats stepping through the panels code yourself.  I've found the rounded corners plugin that ships with panels is a good reference to review when you're stuck.

Creating panels styles can be very powerful. You can define certain styles for your client to choose from, so they can choose what type of display the panel pane will be like. This way you keep the workflow clean, your code under revision control, your themer gets to keep his sanity, and your concious stays clear.

How to create a panels style plugin | manuee – Putting the puzzle together.

WordPress 2.9 is ramping up support for custom post types. It's an improvement, but not nearly as exciting as you've probably been led to believe.

For starters, what is a custom post type in WordPress?

WordPress ships with 4 post types: post, page, revision, and attachment. WP uses a single table, called wp_posts, to store the bulk of its information. Within this table, there is a column called post_type. This column tells WordPress whether an item is a blog post, page, attachment, revision, etc. The idea behind "custom post types" is to add new post_type values (e.g. "event" or "publication"), and handle items differently depending on their post_type.

Custom Fields 101

If any data needs to get saved that doesn't belong in the wp_posts table, it can be saved using custom fields. Each custom field value is saved as a separate row in the wp_postmeta table.

Without the help of plugins (e.g. Custom Field Template), there is no way to auto-assign custom fields to posts depending on their post type. Custom fields are extremely inefficient. Each item is stored as a key/value pair, with the value a LONGTEXT column regardless of what that value actually is (bool, date, integer, etc). If you assign 10 custom fields to a certain post type, then add 5,000 posts, then that's a whopping 50,000 rows cluttering up your wp_postmeta table.

 

What's new in WP 2.9?

get_post_type()
Returns the current item's post type (used within The Loop). This function is identical to $post->post_type.

get_post_types()
Returns an array of all post types.

register_post_type($post_type, $args_array)
Called from within a plugin or functions.php. Only 1 available argument: "exclude_from_search" Ex: $args_array = array('exclude_from_search' => true);

 

What to expect in the future

Currently, custom post types are all but useless without the help of plugins. For example, there is no code within WP core to auto-assign different fields for different post types. The ability to auto-create custom fields depending on the post type would make a lot of sense. There is talk of a UI being added for WP 3.0 to manage custom post types, but only time will tell.

 

WordPress 2.9 is ramping up support for custom post types. It's an improvement, but not nearly as exciting as you've probably been led to believe.

For starters, what is a custom post type in WordPress?
WordPress ships with 4 post types: post, page, revision, and attachment.

WP uses a single table, called wp_posts, to store the bulk of its information.

Within this table, there is a column called post_type. This column tells WordPress whether an item is a blog post, page, attachment, revision, etc.

The idea behind "custom post types" is to add new post_type values (e.g. "event" or "publication"), and handle items differently depending on their post_type.


Custom Fields 101
If any data needs to get saved that doesn't belong in the wp_posts table, it can be saved using custom fields. Each custom field value is saved as a separate row in the wp_postmeta table.


Without the help of plugins (e.g. Custom Field Template), there is no way to auto-assign custom fields to posts depending on their post type.

Custom fields are extremely inefficient. Each item is stored as a key/value pair, with the value a LONGTEXT column regardless of what that value actually is (bool, date, integer, etc).

If you assign 10 custom fields to a certain post type, then add 5,000 posts, then that's a whopping 50,000 rows cluttering up your wp_postmeta table.

What's new in WP 2.9?
get_post_type()
Returns the current item's post type (used within The Loop).
This function is identical to $post->post_type.

get_post_types()
Returns an array of all post types.

register_post_type($post_type, $args_array)
Called from within a plugin or functions.php. Only 1 available argument: "exclude_from_search"
Ex: $args_array = array('exclude_from_search' => true);

What to expect in the future
Currently, custom post types are all but useless without the help of plugins. For example, there is no code within WP core to auto-assign different fields for different post types. The ability to auto-create custom fields depending on the post type would make a lot of sense. There is talk of a UI being added for WP 3.0 to manage custom post types, but only time will tell.

Please ignore this post, which makes the utterly ridiculous recommendation that customers should care about what tools developers use in their work.  Programming is such an individualized task that what works for one person will not necessarily work for someone else.  

That's why, when talking about tools, I like to describe why *I* like the tools and how it makes my tasks easier.  I've tried a lot of different IDEs over the years, and I always come back to jedit.  Some of it is definitely due to comfort, but big IDEs tend to make assumptions about how and where you organize your code, and want you to do all of your work via the IDE.  I like to drop to the command line a lot, to do SVN diffs, commits, and updates.  It feels faster to me, even if it isn't, plus those are the tools I have at my disposal on my server's command line - no fancy GUIs there to guide you.

If the answer is notepad++ you should stay away from that company, no matter how cool the flash design looks.

When evaluating a development shop, you're much better off asking them how they score on the Joel test. It gives you a much more complete look at "the quality of a software team." But Oscar, #9 says "Do you use the best tools money can buy?"  As I read the question, its really asking if you provide them with the best tools to keep them productive and happy.  If someone is a wizard with notepad++ or vim, who's to say they must use anything else?

The recent revelation that at Microsoft, the top developers prefer Old School methods highlights that fancy programming environments aren't necessarily better or make for better programmers.

"When there are five things on the screen, you can burp that out [in text]. But when there are 500 things, [graphical programming] is completely unusable. You zoom in and zoom out and you lose all context. I think it's just smokin' dope."

Keith Casey recently observed to me that "Drupal developers don't seem to think of themselves as PHP developers," and the ensuing conversation, at various times roping in Joe LeBlanc (a Joomla! developer) and Aaron Brazell (WordPress) caused Aaron to write this really thoughtful post. What we've realized is that many of these applications with large communities don't seem to think they're a part of the larger PHP community, and for whatever reason the divide exists, it makes both communities weaker.

PHP is actually a rich language. It has been used from tiny personal projects up to FaceBook and Digg. The collective experience of its community also spans that range and much in between. So there are things the broader community of developers has learned that could greatly benefit Drupal and other open source projects.

As Joe points out in the comments to Aaron's piece, not every application is a Digg. So the PHP community could use the feedback that optimizing for the Digg case might come at the expense of middle-tier uses of the language. And of course it remains a stubborn trope in the Drupal community that object-oriented programming in PHP results in "slower" applications, yet the broader community has learned that object orientation is almost never the cause of slow PHP applications; doing things like having too many database calls is--and that's definitely a problem Drupal has by design (see slide 40 and forward of this presentation).

So both communities would be enriched by the participation of members of the other. I admit I have been more of a PHP developer who happens to use Drupal, but I have attended the DC DrupalCon and a couple of the DC user group meetups. Yet aside from developers who report to me, I haven't seen anybody from the DC Drupal community showing up at a DC PHP meeting.

So if you develop sites with Drupal and know even a little PHP, check out your local user group or consider attending a PHP conference. You might find potential members of the Drupal community and learn some things that could benefit your next Drupal project. And I will definitely bring my Drupal experience to PHP conferences and meetings.

We will both be better off, so if you've been waiting for somebody to invite you or bug you to join in, consider yourself invited!

Keith Casey recently observed to me that "Drupal developers don't seem to think of themselves as PHP developers," and the ensuing conversation, at various times roping in Joe LeBlanc (a Joomla! developer) and Aaron Brazell (WordPress) caused Aaron to write this really thoughtful post. What we've realized is that many of these applications with large communities don't seem to think they're a part of the larger PHP community, and for whatever reason the divide exists, it makes both communities weaker.

PHP is actually a rich language. It has been used from tiny personal projects up to FaceBook and Digg. The collective experience of its community also spans that range and much in between. So there are things the broader community of developers has learned that could greatly benefit Drupal and other open source projects.

As Joe points out in the comments to Aaron's piece, not every application is a Digg. So the PHP community could use the feedback that optimizing for the Digg case might come at the expense of middle-tier uses of the language. And of course it remains a stubborn trope in the Drupal community that object-oriented programming in PHP results in "slower" applications, yet the broader community has learned that object orientation is almost never the cause of slow PHP applications; doing things like having too many database calls is--and that's definitely a problem Drupal has by design (see slide 40 and forward of this presentation).

So both communities would be enriched by the participation of members of the other. I admit I have been more of a PHP developer who happens to use Drupal, but I have attended the DC DrupalCon and a couple of the DC user group meetups. Yet aside from developers who report to me, I haven't seen anybody from the DC Drupal community showing up at a DC PHP meeting.

So if you develop sites with Drupal and know even a little PHP, check out your local user group or consider attending a PHP conference. You might find potential members of the Drupal community and learn some things that could benefit your next Drupal project. And I will definitely bring my Drupal experience to PHP conferences and meetings.

We will both be better off, so if you've been waiting for somebody to invite you or bug you to join in, consider yourself invited!

As of this morning - 09 December 2009 - web2project v1.2 is live!

While there is not a huge amount of new user-facing functionality, the sheer number of fixes and amount of cleanup is staggering.  Since the v1.1 release in September:

• Pedro made some major updates to the iCal handling which added the Task Description and Links to the iCal entry for one-stop shop of information.
• Pedro also added the Brazilian Portuguese translation to core.  Rumor has it that there's an Italian version on the way next.
• Added some creative caching and pre-calculations to the Task Count, Total Hours, Percent Complete, and Worked Hours to speed up the system significantly.
• Changed the PDF creation for reports to use a randomly generated filename.
• Created a GanttRenderer class to centralize the Gantt chart creation with the goal of standardizing behavior and eventually replacing jpGraph completely.
• We've created strong object validation that happens on save.  Whenever you attempt to save a Project, Company, Link, etc, the system makes sure the required fields are actually filled in.  Realistically, some would claim that the Javascript already did some of this on the front end, but that could be bypassed... and we needed something more solid for the API.
• The method signatures - specifically for store(), delete(), check(), and a few other calls - have been standardized.  This by itself isn't incredibly useful yet... but we needed something more solid for the API.
• We did some major refactoring of the core modules based on a code review we received at CodeWorks 2009.  Sebastian Bergmann (phpUnit creator), Stefan Priebsch (OO guru), and Arne Blankerts (security guru) were kind enought to take a look at the code and shared feedback on a number of architectural concepts, OO improvements, and overall code clarity.  These changes aren't immediately visible to end users but we needed something more solid for the API.
• Finally, Trevor and I (mostly him) added about 40 Unit Tests since the v1.1 release.  While we don't distribute them in the release - you have to get them via SVN - they're useful for testing against the growing API.

Are you detecting the pattern here?

Further, we closed nearly 50 items ranging from 8 crash-level bugs to 20 minor bugs to 4 pre-defined feature requests.  Of course, that only covers the things logged as issues.  If you want to see everything of interest, check out the web2project v1.2 Release Notes on our wiki.

In accordance with our quarterly release schedule, this is our final release for 2009.  The next release will be 1.3 in March 2010 with v2.0 scheduled for June 2010.