Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Scotch.io:
Full E-Commerce Integration of Snipcart with WordPress
Jun 17, 2016 @ 11:03:24

The Scotch.io site has a tutorial for the WordPress users out there needing an ecommerce solution and wanting to integrate it seamlessly into your site. They show you how to integrate Snipcart, part of a platform that handles a lot of the common ecommerce tasks for you.

Even though an exponential amount of online tools keep popping up, WordPress remains a domineering web behemoth. More than 25% of active sites run on the famous CMS. Quite a chunk of the whole world wide web.

[...] Many front-end developers I've met and talked to enjoy working with a lean, quick e-commerce solution like Snipcart. But, they also want to give more autonomy in familiar CMS to their merchant clients. Since many of them use WordPress, I thought I'd write this article to provide them with a useful resource.

The post then breaks the process down into a few different steps, each including code and screenshots as needed:

  • Installing the required plugins
  • Show products in the theme
  • Integrate Snipcart's shopping cart
  • Update inventory with webhooks
  • Add Snipcart data to WordPress admin
  • Quick edit of inventory

If you're interested in the full code required for the integration, you can see it over on this GitHub repository.

tagged: scotchio ecommerce solution snipcart wordpress tutorial integration

Link: https://scotch.io/tutorials/full-e-commerce-integration-of-snipcart-with-wordpress

QaFoo.com:
Never Use null
May 03, 2016 @ 13:07:32

On the QaFoo.com blog they've made a recommendation in their latest post - they suggest that you never use null.

When doing code reviews together with our customers we see a pattern regularly which I consider problematic in multiple regards – the usage of null as a valid property or return value. We can do better than this.

Let's go into common use cases first and then discuss how we can improve the code to make it more resilient against errors and make it simpler to use. Most issues highlighted are especially problematic when others are using your source code. As long as you are the only user (which hopefully is not the case) those patterns might be fine.

They talk about some of the most common uses they see for using null in PHP applications including setters for class properties (injection). They point out that in PHP 7 a missing value on a property would result in a Fatal error and make the functionality harder to test overall. They suggest that all required dependencies be injected on object construction instead, making it easier to know the current state of the object on testing. They also talk some about using null as a return value, how it could make debugging difficult and a solution that could make more sense - throwing an exception instead.

tagged: never use null return value injection setter solution suggestion debugging

Link: https://qafoo.com/blog/083_never_use_null.html

Christian Mackeprang:
Newton's 3 Laws of Software Craftsmanship
Apr 13, 2016 @ 11:51:11

In this post to his site Christian Mackeprang shares what he calls "Newton’s 3 Laws of Software Craftsmanship" - some guidelines to follow in your development to help make things a bit more sane.

Are there unbreakable laws ruling the process of software development? I asked myself this question while reflecting on a recent project, and the answer leads to many conclusions, some already known and some more revealing.

Scientific laws reflect reality and cannot be broken. They have strong implications onto how we build things. For instance, there is no point in building a car with vertical propulsion once you’ve observed that the law of gravity will prevent your car from drifting into space anyway. But software lives in the logical world. Does it really follow any laws?

He shares his three laws and provides a bit of background for each:

  • "Under fixed circumstances, every solution will behave the same way, unless it has been modified."
  • "The impact of a technical decision is directly proportional to the size of the project and to how much of it is affected."
  • "Every technical decision comes with an implied tradeoff."

He also includes a "how to be mindful" section for each of the laws, giving you both practical and mental tips to help you follow it.

tagged: threelaws newton software craftsmanship solution decision tradeoff

Link: http://chrismm.com/blog/newtons-3-laws-software-craftsmanship/

Pádraic Brady:
Securely Distributing PHARs: Pitfalls and Solutions
Mar 04, 2015 @ 11:46:10

Pádraic Brady has a new article on his site talking about the secure distribution of phars (PHP archive files) including some of the common pitfalls and potential solutions.

The PHAR ecosystem has become a separate distribution mechanism for PHP code, distinct from what we usually consider PHP packages via PEAR and Composer. However, they still suffer from all of the same problems, namely the persisting whiff of security weaknesses in how their distribution is designed. [...] [Several security-related issues introduce an element of risk that the code you receive is not actually the code the author intended to distribute, i.e. it may decide to go do some crazy things that spell bad news when executed.

He shares some of the steps he's taken to secure his own phar for a CLI application with things like:

  • Distribute the PHAR over HTTPS
  • Enforce TLS verification
  • Sign your PHAR with a private key
  • Avoid PHAR Installer scripts
  • Manage Self-Updates securely

He finishes the post with one of the most important parts of the article - a reminder to do all of the things on the list above consistently.

This is not an outrageous outcome to introducing proper security on PHAR downloads. Go forth and do it for all PHARs. Help create an environment where distributing and installing code in secure ways is the normal expected thing to do.
tagged: secure distribution phar solution tls https privatekey installer selfupdates

Link: http://blog.astrumfutura.com/2015/03/securely-distributing-phars-pitfalls-and-solutions/

SitePoint PHP Blog:
MVC – a Problem or a Solution?
Jul 28, 2014 @ 11:42:36

The SitePoint PHP blog has a new post by Jeroen Meeus that wonders if MVC is a solution or a problem when it comes to developing web applications.

Repositories, Adapters, MVC with all it cousins, SOLID, RTFM… As a (PHP) developer, those words are thrown at you from every corner of the web. And I hate it, I’ve had enough. Stop telling me what to do and show me those kittens instead. [...] When solving the web-application problem, we are forced to use MVC. The dev community often frowns upon those who don’t use it, but seldom lets those they’re frowning upon ask why. [...] MVC doesn’t solve the Code complexity problem. It doesn’t solve the code reuse or no-flexibility problem either. And it doesn’t guarantee decoupled code.

He goes on to talk about how design patterns don't "solve problems". Rather they help us as developers by providing a best practice we can follow to get the job done. He suggests, though, that MVC has become "the new Singleton" but it has been used so much in so many different ways, it's boarding on the point of being abused.

Depending on the situation, and the problem at hand, different patterns can help you write robust, secure and understandable code. Just be careful using them – if you catch yourself using the MVC pattern for a 1-pager, ctrl+a del.
tagged: mvc designpattern problem solution abuse

Link: http://www.sitepoint.com/mvc-problem-solution/

Docnet.nu:
SSL And PHP Streams - Part 1: You Are Doing It Wrong™
Jun 26, 2014 @ 09:54:40

On the Docnet.nu blog today they've kicked off a series looking at the use of streams and SSL in PHP and asking if you're doing it wrong in your current applications. The focus is more on the security aspect, breaking it down into a set of common problems (and how to work around them).

The upcoming PHP 5.6 release brings with it a number of improvements to encrypted PHP streams, both internally and externally. In these articles I will try to cover the most important changes, and how they affect your code. This article will focus on how to get the best security level in code that needs to be run on PHP versions below 5.6, and highlighting some of the gaps in the currently available functionality. Version 5.4.13 is the earliest version that supports all the options described below - and if you are running something earlier than this, then you really should consider upgrading to at least the latest version of the 5.4 series 1.

Their list is made up of six different problems:

  • Problem 1: Peer Verification
  • Problem 2: Cipher Lists
  • Problem 3: Protocol Support
  • Problem 4: TLS Compression Attack Vulnerability
  • Problem 5: Cipher Order
  • Problem 6: TLS Renegotiation Attacks

Each problem comes with a brief description of what it is and why it's an issues. Some also include code snippets showing how to correct the issue, usually relatively simply.

tagged: streams problem list solution https tutorial

Link: http://www.docnet.nu/tech-portal/2014/06/26/ssl-and-php-streams-part-1-you-are-doing-it-wrongtm/C0

Timoh's Blog:
Aggressive password stretching - A solution to the low-entropy keys problem?
Nov 29, 2013 @ 10:15:30

While not specifically related to PHP, this new post from Timoh looks at the idea of "aggressive password stretching" to help with a common problem in password-based systems - the poor choice of passwords from the application's users.

Practically speaking, “weak” means a user generated password will not contain enough guessing entropy to resist an adversary who managed to gain the user database dump, and who is able to run efficient offline attack against leaked hashes. Here comes in the need to make adversary’s job harder, which is achieved by using the above-named algorithms.

He doesn't talk much about the actual password hashing itself, instead focusing on how the password stretching - the addition of more information not from the user (usually an automated source) to increase it password entropy. He goes through some of the math about how much extra work is required for an attacker with this method and some of the problems that can come with it. He talks about how much time should be spent in the hashing of the passwords and suggests that it's "a matter of finding a sweet spot between you and attacker’s patience and the security gain" and not just about the security.

A bit more on the PHP-specific side, he briefly looks at the password_hash function and some of the defaults the more current frameworks use (hint: bcrypt all the things).

Proper password hashing is clearly not enough to make sure the password hashes are not weak. The other half of the job is a good password policy. No algorithm or setting will save passwords like “password” or “12345” etc. This is why we need to make sure the user’s password will initially contain enough entropy itself.
tagged: password stretching hashing aggressive entropy solution

Link: http://timoh6.github.io/2013/11/26/Aggressive-password-stretching.html

Anthony Ferrara:
Reinvent The Wheel!
Aug 06, 2012 @ 09:03:19

In this recent post to his site, Anthony Ferrara takes an the phrase "reinventing the wheel" and wonders if, maybe, it's not such a bad thing sometimes.

"Don't Reinvent The Wheel" is a phrase that we hear used all the time in software development. Usually it's used in the context where a library exists to do what the user wants, but they are writing their own. While the sentiment is usually correct, I can't stand the implication of the phrase. Therefore, I can't stand it when people use that phrase without understanding what it really means. Let me explain...

He notes that, while there might be things out there that do something well, it doesn't mean that the "wheel is perfect" and you shouldn't venture out and try something new. He points out two places where it could be good - when a general solution doesn't work and for education/research.

Even as a senior developer, if you never try to reinvent the wheel from time to time, you'll never push your capabilities. You'll never expand your conceptual model of problems. And if you never do that, the world will blow past you.
tagged: reinvent wheel opinion development education solution

Link:

Anthony Ferrara:
Is Autoloading A Good Solution?
Jul 20, 2012 @ 15:56:30

In his most recent post Anthony Ferrara takes a look at autoloading - mostly asking the question of whether the problems it has really outweigh the benefits.

The real problem that autoloaders solve is to load dependencies. [...] The normal logic that's used to justify autoloading over manual dependency loading in production is that it only loads the classes you need. Therefore you save the parsing costs of classes that you don't need. But surely that additional run-time loading has costs. So I decided to setup a test to see how expensive that additional run-time loading costs us, and to prove whether or not autoloading is worth it in production.

He gives an example of the two methods - using the spl_autoload_register method to define a loader and loading them with a defined file path instead. He found the autoloading version slower than the hard-coded (by quite a bit) but how, when the number of files is reduced, the performance gets much closer. He also briefly looks at two other pieces of file-related functionality: file_exists and require_once.

tagged: autoload solution performance static path fileexists requireonce

Link:

Lukas Smith's Blog:
Query parameter handling in Symfony2
May 14, 2012 @ 11:56:37

Lukas Smith is looking for feedback about a question that's been in his mind a lot lately - can the handling of query parameters be made better for the Symfony2 framework (and even easier to use).

Obviously you can already access query parameters today already but it could be easier. Essentially what I want is a way for developers to easily configure what query parameters they expect and what values they expect. This is useful for several things like easier reading and validating of query parameters, self documenting API both for API docs for humans but also for machines.

He's asking for feedback and ideas from the community on a proposed solution that could make things more flexible. He also briefly mentions the route matching and how qurey parameters could cause them not to match:

For one I don't think that a mismatch on a route requirement of a query parameter cause the route to not match. However then it can quickly become confusing for the end user or it would require adding more and more syntax to handle all the different cases.
tagged: symfony2 query parameter handling solution routing match

Link: