Romans Malinovskis has a post on his Medium.com site sharing what he calls a "pragmatic approach to reinventing ORM" with his thoughts about a different approach to this commonly used database interface.

It’s been over a year, since I posted my first highly debated post on Reddit: Reinventing the faulty ORM concept. Gathered information helped me design and implement an alternative pattern to ORM with many important advantages and that has reinforced my belief that ORM is faulty.

He's broken the article up into a few sections with details and thoughts for each along the way:

• Why ORM is important?
• Why ORM is broken?
• How Agile Data differ in approach?
• How Agile Data qualify production/enterprise use?
• Notes on architectural decisions in Agile Data (OOP vs Decoupling)

That final section focuses mostly on the decoupling aspect and the Agile Data library (a Data Mapper) that can be used and solves some of the common ORM problems he mentioned in the earlier sections.

David Sklar has a post to his site showing you how to fix broken UTF-8 characters in content being passed through the normal string functions.

When working on the i18n bits of Learning PHP 7, I had a problem. My example showing how plain string functions such as strtolower() and strtoupper() mangle multibyte UTF-8 characters was making the book formatting/rendering pipeline barf. The processing tools are expecing nicely formatted, valid, UTF-8 encoded HTMLBook files. It didn’t like the mangled invalid UTF-8 characters in my example output.

To fix this, I wrote the following function to replace invalid UTF-8 sequences with the Unicode Replacement Character (U+FFFD).

He includes the code for this method that walks through the string, character by character, and checks the bytes it contains to see how it needs to be translated. There's plenty of comments in it too, explaining what it's doing as it goes along.

In a follow up to his previous post about how PHP is broken (and what can be done to fix it), Court Ewing has this new post with a few suggestions on how PHP development could be better, but admits that PHP itself is not broken.

It is no secret that the PHP development process has never been a shining example of project organization or quality assurance. Until recently, some of the most important aspects of any project's development cycle were either entirely lacking or were ill-defined. Worse, there was little in the form of systemic quality assurance. Fortunately, the core devs did not ignore these issues, and they've been pushing really hard to improve on these areas over the past few years.

He points out two things that he sees as things that could be improved in the overall process of developing the language - noting that failing automated tests are ineffective and that communication is a key factor in the trust developers have in PHP.

The core PHP developers have long been a key component of [the amazing things the language can do], and none of progress that modern PHP applications have made would be possible without their ongoing efforts. As a result of those efforts, PHP is a stable, secure, and beautifully-practical language that is both easy for novices to wrap their heads around and experts to build the most-used web applications the world has ever seen.

On the Internet Super Hero blog, there's a post that looks at how PDO is implemented in PHP and wonders if the PDO::FETCH_UNIQUE constant is broken (as something to fix before even considering the move to PDO2).

I spent quite a lot of time comparing the different behaviours of the various drivers in the hope I could find out how PDO drivers are supposed to work. The PDO documentation and the specification do not cover each and every detail. PDO really needs some love...

He picks out the FETCH_UNIQUE constant as one that needs a little work and tries to track down exactly what it's doing. One issue he found was that it requires combination with other flags to make the unique part of it work correctly (like FETCH_OBJ or FETCH_COLUMN). He works through several examples, both ones that apply the unique call and others that don't, comparing the results.

Dave Dash has posted about a method he developed, using a custom prepend file, to correctly obtain the PATH_INFO information for his server.

symfony and other applications rely on the server's PATH_INFO being set properly. Unfortunately, I use a nonstandard server that doesn't natively support CGI [...] but I can't figure out how to do a urldecode in my configuration.

To get around the issue, he created a file he prepended to each request (via auto_prepend_file) that took the value and urldecoded it to put it in another $_SERVER value.

Christopher Kunz wonders in this new post about the filter extension that's been getting so much press in the PHP community lately - specifically about it being active despite not being finished.

Basically, what he [Ben Ramsey] conveyed to me (and his blog entry supports this) was not to use ext/filter or Zend_Filter at all. Nearly every second slide regarding functions of the ZF component or the extension contained remarks like "This doesn't work yet, it's a TODO", "this won't validate XY properly".

Of course, other community members (Pierre-Alain Joye and Ilia Alshanetsky) come back in the comments to refute Christopher's claims. They note that it's not the filter extension that has the problems, rather that some of the features are missing outside of the core filtering functionality.

Christopher Kunz wonders in this new post about the filter extension that's been getting so much press in the PHP community lately - specifically about it being active despite not being finished.

Basically, what he [Ben Ramsey] conveyed to me (and his blog entry supports this) was not to use ext/filter or Zend_Filter at all. Nearly every second slide regarding functions of the ZF component or the extension contained remarks like "This doesn't work yet, it's a TODO", "this won't validate XY properly".

Of course, other community members (Pierre-Alain Joye and Ilia Alshanetsky) come back in the comments to refute Christopher's claims. They note that it's not the filter extension that has the problems, rather that some of the features are missing outside of the core filtering functionality.

The PHPWomen have posted a quick note about some of the broken-ness that's happened in the latest release of PHP, version 5.2, and the go-pear.phar file in the Windows releases.

Greg Beaver fixed it immediately, but the fix was NOT incorporated into the 5.2 releases for windows - however the file for the source releases is correct. If you are getting errors that look like this

If you're getting an error like they mention ("cannot use scalar value"), you'll need to go over and grab the latest Go-pear from the CVS repository and install it instead.

The PHPWomen have posted a quick note about some of the broken-ness that's happened in the latest release of PHP, version 5.2, and the go-pear.phar file in the Windows releases.

Greg Beaver fixed it immediately, but the fix was NOT incorporated into the 5.2 releases for windows - however the file for the source releases is correct. If you are getting errors that look like this

If you're getting an error like they mention ("cannot use scalar value"), you'll need to go over and grab the latest Go-pear from the CVS repository and install it instead.

InternetNews.com starts off their latest article the same way Rasmus Lerdorf started off his keynote at php|works this year - "The Web is broken and it's all your fault."

He said the current state of the Internet includes a litany of broken items, but with a little help from PHP there may well be some hope for the Web yet.

The article talks about some of Rasmus' other thoughts on the status of the web, and how, with the right functionality and knowledge spread out through the PHP community, the language can compensate for some of the "stupidity" that web programmers (and users) regularly see.

He also talks a bit about a "rich application delivery system", MySQL versus PostgreSQL, parsing and compiling speed, and opcode caches.