The PHPUgly podcast, hosted by PHP community members Eric Van Johnson, John Congdon, Thomas Rideout has posted their latest episode: Episode #110 - Tom is always wrong.

This month the team discusses BeEF - The Browser Exploitation Framework Project

Other topics include:

• memorialized Facebook accounts
• applications tracking with ultrasonic signals
• backdoored Docker images removed from DockerHub

You can listen to this episode either using the in-page audio player or by downloading the mp3 directly. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter to get updates when new shows are released.

On The Nerdery's blog today there's a new post suggesting that most of the reports of WordPress' insecurity are wrong and they're going to set the record straight.

I have often heard the remark “WordPress is insecure!” My response is “Where did you hear that?” and “When did you hear that?” [...] WordPress core is, in fact, very secure, just as secure as any other Content Management System, just as secure as any other software suite or Operating System. Security issues most often arise from administrators and users. In other words, you are the weakest link.

They suggest that between the high-profile nature of WordPress and the constant (sometimes wrongful) warning being put out there about its security, people perpetuate the message sometimes unknowingly. Besides the human element being the largest risk, they also point out a few others including issues around shared hosting and the availability of easy-to-find tools to exploit flaws. They talk about a brief history of the WP core security and how they define the real security of a product - how quickly it responds to security issues. They also include a few suggestions for you to help harden your own WP installation.

In this post to his site J-P Stacy suggests that its neither the developers or the language that's the real problem with PHP. He wants to get beyond the typical anti- and pro-PHP rants and look at what makes for good web applications, specifically PHP ones.

I think there's a sense in which PHP's success - widespread and inclusive - is at the very same time its failure - quickly learned and nonselecting. Communities like PHP's can evolve in the same way as any other population evolves: individuals exhibit random traits; a particular environment translates those traits into a likelihood of longevity; over time, individuals or their descendants exhibit different traits, adapted to suit the environment. But if the environment is not particularly harsh, then very little selection occurs. Only a negative evolutionary pressure, a harsh environment, can if you like weed out a lack of developer talent.

[...] There's no escape. We must live with the likelihood that untalented developers can end up building charmless applications, and a (unfairly large) proportion of those will be PHP applications.

He does make one suggestion that could help the community and those developers new to the language and in need of training - good management (or, as he describes it, "direction"). He suggests three areas that could be managed to help make the PHP ecosystem better as a whole - the people, the processes for making good software and the embracing of standards known for success.

About a month back Samuel Levy wrote up a post sharing some of his thoughts on PHP, mostly centered around one idea - that PHP is the right tool for the job (for all the wrong reasons).

When people complain about PHP being a horrible language, not fit for human consumption, they will often talk about how the features of their favourite language are far more refined; have been designed with elegance in mind; are consistent and secure. And you know what? They're right. But PHP is still a better tool. [...] And it shouldn't be. It really shouldn't. I want another language to knock PHP out of the way. [...] I can't, though, because PHP does one thing really well that no other language seems capable of doing. It works, out of the box, for people who don't know what they're doing.

He goes on to talk about the "installation" required with running PHP scripts and how it makes it mostly "idiot-proof" to use. He points out that PHP has a definite niche in the world of web development languages - one that has a larger need that some others.

This is the challenge for all the people who want to complain about PHP - if your chosen language is so much better (and I have no doubt that in many ways, it objectively is), then make it accessible in the way that PHP is. Until then, keep that double-clawed hammer in your shed in case you want to make... burgers...

On SitePoint today there's a new post from Eran Galperin (of Binpress) about how, if you're jumping immediately to custom software development, you're probably doing it wrong.

Code reuse is largely accepted as "best practice" in our industry. Code reuse has many advantages, such as a smaller code-base which is easier to grok for developers. It's easier to maintain and optimize, since you can make less changes in order to achieve the desired results. Many modern techniques and tools were created in order to better reuse and modularize code. But while we're reusing code, we're duplicating effort. The same code is being written over and over in different places, wasting time and money.

He suggests that custom development should always be a last resort for software development, that there's plenty of other (open source) software out there that meets many of the needs businesses have. In his opinion, component-based development is the future of the industry - pieces that fit together with common interfaces and are larger than the sum of their parts. He sees a "commercial open source" model emerging from the current state of things. This model could result in more well maintained OS projects and more functionality being released as a part of it.

What we have currently is increasing noise, as more and more people have easier access to start programming and publishing their projects. We need to streamline the process and add that missing financial element that makes it sustainable and repeatable.

PHPClasses.org has posted their latest "Lately in PHP" podcast today with mentions of PHP 5.3.8 and some of the wrong ideas that are common when referring to PHP (from their previous post).

Another PHP 5.3 version was released. Manuel Lemos and Ernani Joppert discuss whether you should upgrade to this new version of PHP, as well if you should try the new PHP 5.4 beta version. They also talk about the repercussion of the article about the Wrong PHP Ideas You Should Get Right and why it is important to clarify PHP haters and lovers about these PHP misconceptions.

You can either listen to this latest episode through the in-page player, by downloading the mp3 (25MB) or by subscribing to their feed and getting the latest right in your reader of choice (even iTunes).

On the ProDevTips blog today Henrik describes a situation where he "tried to be clever" with the array_map and array_filter functions and some of the confusion in their usage.

I knew array_filter existed and what it was all about since before, however I started working with something requiring array_map first, all well and OK, array_map looks like this: array_map(’callback’, Array). So then I assumed I could use array_filter in the same fashion, big mistake.

He was caught by the parameter order difference between the two and problems with how the callbacks worked. In the end, he he spent an hour to create a function to search an array for a partial match and didn't even end up using the array functions (opting for calls to stripos instead).

If you've ever wanted to go to a technology conference (there's several PHP ones out there!) but have talked yourself away from them with excuses, you might want to check this new post from Lorna Mitchell to see if any of them match up. She dispels some of the common misconceptions about attending conferences - five, to be exact.

I can quite appreciate that different people come to conferences for different reasons, but I cannot accept that people actively avoid conferences because they think its not for them - and the reasons for this, from people who have never been to a conference, are wild and varied. Most are based on misconceptions and I'd like to take the time to examine some of these.

She looks at some of the most common:

• I won't know anyone
• It's too expensive
• My employer won't pay
• I might have to talk to people/strangers
• I haven't been to a conference

These along with a few other recommendations can rid you of some of the worries you might have over attending and maybe give you something new to talk to your manager about when the next conference rolls around.

In this new post to his blog Timothy Boronczyk has a few suggestions about what's wrong with the current implementation of object oriented programming in most languages (including PHP).

Proponents of Object Oriented Programming feel the paradigm yields code that is better organized, easier to understand and maintain, and reusable. [...] If objects truly model the way people think of things in the real world, then why do people have a hard time understanding and working in OOP? I suspect the problem might be the focus on objects instead of actions.

He goes on to explain that, in his opinion, the functionality would be more understandable if it focused on the actions from the user's point of view rather than what the object itself can do.

The way some OOP languages (like Java and C#) force objects on the programmer borders on the absurd. [...] Sadly though, that decision isn't left to the programmer who has been tasked with developing and maintaining a system.

In his latest blog post, Aaron Wormus asks the PHP community exactly "what's wrong with PEAR?"

I didn't attend Theo's talk, so the only information that I got was from the blog entries and slides. I realize that this short presentation was humorous, but it still brings up some points that have been nagging at the back of my head for a while now.

The comment in question is part of the Six Reasons PHP Sucks lightning talk.

The comment jokes about the quality of PEAR code. OF course, as Aaron notes, these types of comments aren't anythng new. The real issue at stake is that people don't understand PEAR. To help further the cause behind this (in)famous set of libraries, he's written an article for php|architect to dispell some of the myths.