If you're a WordPress user and you've ever wondered about the process of creating your own custom plugin, this new tutorial from Delicious Brains might be just what you need. In it they go through their process for creating a plugin, from the initial ideas to release.

If you’ve been reading our blog for a while, you’ve probably seen some of our tutorials on developing plugins using different technologies like React and Vue. But when not writing examples for blog posts, we rarely if at all dive into creating a new plugin – there’s a lot more that goes into it before we write a single line of code.

In this week’s post, we’ll be taking a look at everything we do to create a new product or WordPress plugin. We don’t adhere strictly to any specific software development process, but the method we’re using currently seems to work well.

They then walk through the process, step-by-step, with a summary of each and helpful hints as you go along:

• Research and Brainstorming
• Wireframes
• Developing the Plugin
• Reviewing and Testing

The post ends with some concluding thoughts about the amount of work required, scope creep and the value of planning/wireframes.

The PHP Roundtable podcast has posted their latest episode, the second part of a series devoted to working "from idea to production" - Episode #39.

We get an update on status of the project we discussed in part 1 and discuss next steps to take our dance event management app idea to production.

Like in part one of the series, host Sammy Kaye Powers is joined by guests Steven Maguire, Jocelyn Lopez and Glen Hinkle. You can watch the recording of this live show either using the in-page video player or directly on YouTube. If you enjoy the show and want to see future episodes, be sure to subscribe to their feed and follow them on Twitter for updates as they're released.

The PHP Roundtable podcast, hosted by Sammy Powers, has a new show posted (#21) staring off a series about moving from just an idea to a production application. His guests for this episode are Steven Maguire, Jocelyn Lopez and Glen Hinkle.

We discuss an idea for a web app and identify ways to turn it into a real-life product on the web.

We start with describing the domain and the problems the app should solve. Then we identify the personas that will interact with the app. We discuss the features features the app should have to fix the problems and we sort all the features by priority. Finally we talk about timeline, deliverables and next steps. The app we discuss will be launched to production by the next airing of this multi-part series of taking an idea to code.

You can watch this latest episode either through the in-page video player or directly over on YouTube

In Reddit.com there's a great discussion all started by a simple question - What would you change about PHP if you could dictate the next major version?

We know that PHP has flaws, though it's the best language for web programming, at least in my opinion. How would you improve it?

There's tons of answers (some valid, some are just trolls coming out to play), here's just a few:

• Named parameters
• Add scalar type hinting
• True multi-threading support
• Property accessors
• Strings as objects
• A native namespace
• Return typing
• Default autoloading

There's lots of discussion around some of these (and plenty of others not even mentioned) so be sure to check out the full post for more great ideas.

In this new post Marco Tabini gives his take on "language haters" and how it's less about the language and more about what you do with it.

The reason why I’m here is that, on occasion, a person decides that it’s time write Yet Another PHP Bashing Post. Typically, this is followed by a bunch of Posts Defending PHP. [...] Saying that PHP is horrible or great is no more useful than saying that a hammer is horrible or great (regardless of the number of claws it comes with). [...] The real question is whether PHP - or any other technology - is good for you.

He goes on to mention current successful projects that use PHP, but focuses on the people and the ideas that made them happen, not the language "behind the scenes". He also comments on what he thinks makes a good programmer (and one that has matured past the "X language is the best!" stance):

And this brings me to the crux of the matter: The trick to being a great programmer is to learn as much as you can about as many programming languages and techniques as you can. Eventually, you’ll learn that any language is excellent at some things, good at others, and a poor choice for many others. It’s all about the context, and finding the right tool for the job.

Tony Lukasavage has a new post to his blog about debugging your PHP applications with IntelliJ and XDebug on a WAMP install.

If you are a serious PHP developer and have not given debugging a fair chance, or a chance at all, you are killing yourself. So let's do this thing from the ground up. WAMP, XDebug, IntelliJ, and magic. Follow these steps (for Windows) to reach my recent state of elightenment and PHP debugging bliss.

It's a sixteen step process, but don't let that scare you off - it's made up of lots of little steps like "make a phpinfo() page" and "download IntelliJ IDEA". The rest is actually setting up a new PHP project, dropping in a breakpoint and mapping the scripts to run on your local machine's WAMP install.

Simas Toleikis has posted an interesting idea for a validator that would look at the incoming source of an application/script and determine what the requirements for it might be.

How about creating a PHP code validator? Got this idea by looking at tokenizer and reflection extensions. I doubt I will find the time to work on this myself but then someone else might be interested to pick it up. From user’s point of view there will be a form made of a large textarea box and a single file upload input. One could paste code snippet on that textarea or upload a ZIP'ed source code archive (or a single .php file) for validation.

His proposed result would show a list of "Required Extensions", PHP versions, E_STRICT compatibility and possibly total lines of code in the project. He points out a few issues that might pop up in writing such a tool such as the requirement for it to be able to use the tokenizer extension itself (a sort of catch-22 since it's not always installed).

Michael Kimsal (and his bother Mark) were talking about the state of ecommerce applications, specifically about the latest "hot topic" software - Magento.

My brother Mark has been doing a long term project based on Magento doing a lot of custom work on top of it, and has told me many points, both good and bad, about it.

According to Michael and Mark, speed of the application is a big hindrance. They also mention two points that could help make an ecommerce system so much easier to integrate into the "blogosphere" - publishing a blog feed of some of the user feedback about orders/products/etc and accept trackbacks from an external blog post reviewing the products.

Michael Kimsal (and his bother Mark) were talking about the state of ecommerce applications, specifically about the latest "hot topic" software - Magento.

My brother Mark has been doing a long term project based on Magento doing a lot of custom work on top of it, and has told me many points, both good and bad, about it.

According to Michael and Mark, speed of the application is a big hindrance. They also mention two points that could help make an ecommerce system so much easier to integrate into the "blogosphere" - publishing a blog feed of some of the user feedback about orders/products/etc and accept trackbacks from an external blog post reviewing the products.

On The Bakery (Everything CakePHP) blog today Tulio Faria shares some ways to organize your CSS files to where they can be autoloaded through your CakePHP application.

There's five different ideas that he presents:

• CSS files named without any link with controller names
• CSS with the same controller name
• CSS file with the same name of controller, but only if CSS file exists
• one CSS file for each method of controller
• a CSS file for each method of controller, a little bit more organized

each with their own code and explanation. Tulio also notes quickly that he prefers the last one, keeping things a bit cleaner and more organized.