There is no secret to becoming a Joomla rockstar. In fact, it's really easy if you think about it. Here are 3 (yes, 3) easy steps to becoming a Joomla rockstar:

Step 1: Build a website with Joomla.

Step 2: Learn from your mistakes.

Step 3: Repeat steps 1 and 2.

Dear Open Source Matters,

I've noticed a lot of controversy brewing over your recent announcement that you've hired a PR firm to drive awareness of the Joomla project. This is a tough issue with excellent points on both sides. There is clearly a need for better PR for Joomla. This situation, ironically, is a perfect example of that need. There is also clearly a need for more community involvement and input in decisions like this. Jen Kramer makes some excellent points about this in her recent blog post "VOXUS's first PR problem for Joomla".

But the PR situation isn't really why I am writing this. There have been other situations like this in recent months that have caused similar outrage and upheaval in the community, and I'm afraid something gets lost in all of this. Most of us truly appreciate you and the work that you are doing to advance Joomla as a project and as a community. We may disagree with some of your decisions and actions, but we appreciate the countless hours you spend free of charge working to help make Joomla the best it can be. It is a thankless job that most of us can't or won't do for one reason or another, so thank you for taking the time to do it.

Whether we agree or disagree on matters of policy or decisions that you have made, at the end of the day we are still a community. My sincere hope is that none of us lose sight of that.

Respectfully,
Cory Webb

Session storage is a very important aspect of web applications. In its simplest form, a PHP session allows data to be stored temporarily on the server and accessed throughout a user's time on the site. When that user leaves the site or is inactive for a certain amount of time, the data is destroyed. While anonymous sessions are common, sessions are usually associated with user logins. When a correct username/password combination is entered, a session is created around that user's access information and then read and checked every time that user loads a page. As a developer, you can access this session functionality to enhance your extensions.

Debugging PHP applications has always been a bit of a challenge, as the environment is so distributed. At the minimum, there is a web server, the PHP interpreter, and the web browser. While there are tools that add debugging environments to PHP (such as XDebug), you don’t always have access to install them on the server you’re working with.

Fortunately, you can gain some reasonable debugging capabilities through FirePHP. When you want to dump objects or variables back to your browser without having to do so in your HTML, FirePHP is ready for the task. It can also be used to handle code traces and PHP errors.

FirePHP is both a Firebug extension and a PHP library. When the PHP library is in place, special HTTP headers containing JSON objects are created. Firebug reads the HTTP headers, decodes the JSON, then shows the variables in the console. Since the output body is unaffected, it is extremely useful for debugging XML, JSON, PDFs, images, or other non-HTML output generated in PHP.

Today's security topic is inspired by a recent exercise I went through - testing a server for PCI compliance. For those who are not aware PCI is a security standard for accepting credit cards.

According the website for PCI they state their mission as follows:

"The PCI Security Standards Council’s mission is to enhance payment account data security by driving education and awareness of the PCI Security Standards. The organization was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa, Inc."

I started HowToJoomla on September 8, 2006 with a post about Must-have Joomla! components. In that time, the site has seen 120 new articles, 3 different designs, and 5 guest writers. We've seen the site grow from a one-man blog/tutorial site to a 50,000 unique visitors-per-month, 5-writer team of Joomla! experts sharing insights, tips, and tricks on our favorite web content management system, Joomla!.

As we look toward the future of HowToJoomla, we realized that the current design just wasn't going to be sufficient to fulfill our vision of providing useful, accessible information to the Joomla community. To that end, I am pleased to announce the upcoming launch of HowToJoomla 4.0! Here is a sneak peek of the new site.

Something I have run into frequently during module development is the need to allow multiple instances of that module on a single page. Joomla!, of course, handles 99% of the work involved, but there are a few tricky aspects to making this work. One is the need to eliminate styling conflicts, especially in themed modules. If you only use generic classes and then load multiple theme/color stylesheets, the end result can be unpredictable to say the least.

Long-time users of Joomla are quite familiar with content plugins. When you want to take some user-entered text and reformat it into something else, there’s nothing quite as handy as having a content plugin ready to do your bidding.

However, Joomla 1.5 brought some subtle behavior changes. In Joomla 1.0, content plugins act on both articles entered through the Article Manager, as well as HTML entered in user created modules. When a Joomla 1.0 content plugin is recoded for 1.5, the original effect still takes place on content items, but module output is left unchanged.

What happened? Content plugins in Joomla 1.5 are designed to only act on articles managed through the Article Manager. This will seem inconvenient to people used to the old behavior, but there is a good reason for this change. While many content plugins reformat user-entered HTML, others add markup near the article title or just after an article is output. Also, some content plugins are designed to do additional tasks when articles are saved. These actions do not make sense within the context of a module, so content plugins no longer run on them.

While this good in that it enforces consistency, it also poses a problem. Now that content plugins only work on articles, how do you reformat markup coming from modules? Fortunately, there are a couple of workarounds in Joomla 1.5 achieving similar (if not better) results.