The Symfony Finland site has posted a new tutorial showing you how you can share state in a Symfony application between Twig, React and other Javascript-based applications.

Front end development has certainly grown up in the last few years. UI logic is increasingly being moved to the client side, but the traditional server-rendered views aren't going anywhere soon. And they shouldn't.

The two methods will live alongside each other and you'll have to work with two worlds. Let's explore an idea how to make this pleasant to work with, by sharing state between Twig templates and JavaScript.

The post starts with some background on a case where this kind of sharing was a requirement and, while the initial version was scrapped, a prototype application was born. He details what this prototype showcases (which JS libraries) and links to the Javascript involved over on GitHub. They then get into the code examples showing the creation of an AppState object that handles the serializing of the state information and store the result in the database via a Doctrine connection. This value is then output to the pages that require it, making it available to the frontend application (Vue.js, React or plain Javascript).

On the Stomt blog today there's a post showing how you can share components across Laravel/Lumen applications using a simple structure and making things like microservices easier.

In this blog post, we show a way to split up large Laravel applications into smaller micro-services, in our case Laravel & Lumen applications, and the advantages and pitfalls it brings with it. As a result, we sped up our applications by more than 30% and achieved greater maintainability, too. These principles can, of course, be easily applied to other frameworks.

A lot of functions are needed in our REST API as well as in our administration panel. [...] While we still have a “monolithic” codebase, we have multiple completely independent backend applications. You might want to call them “micro-services” (because it’s so trendy).

These microservices required similar functionality and splitting those out into shared components made sense. They walk you through some of the basic requirements they had when splitting the application and how the components are structured. They then shift over to the Laravel/Lumen side and show how multiple applications can be hosted via the same installation and where the shared components fit in. They show how to define namespaces to load the components and set up the providers so Laravel/Lumen knows how to use them.

In his latest post Larry Garfield talks about the Composer problem that was recently brought up by the Gentoo linux project and is related to how Composer packages and system-level shared libraries differ.

This is not a new complaint; Other distributions have complained about Composer's impact before. But fundamentally I think the issue stems from having the wrong mental model of how modern PHP works when viewed from a distribution or sysadmin perspective.

In a recent heated GitHub thread, several people referred to PHP "linking" to 3rd party libraries, as if they were shared C libraries. That is simply not the case. Neither "static linking" nor "dynamic linking" really applies to PHP. From a sysadmin perspective, PHP is closer to highly complicated bash scripts than anything else.

Larry starts with a bit of history on the subject, pointing out the two methods most developers used PHP code: copy/pasted from the web or installed via PEAR. He talks about the common issues with both approaches. He then talks about how modern PHP development and Composer related and how, from a sysadmin perspective, Composer is the "compile" step of PHP and only supports static links. He also makes some suggestions to the distribution packagers around how to handle these system-level Composer dependencies (and how to treat it like a "binary" if needed).

The mistake here is trying to treat dependent packages of modern PHP applications like shared libraries. They're not. The community has spoken, and PHP simply doesn't work that way anymore. Fighting that is a losing battle. But by viewing composer as a compiler, distributions can still slot PHP into their typical workflows and get all of the security update ease that they're looking for.

Rob Allen has a post to his site talking about using Composer with shared hosting, showing how to use this popular tool even if you're on a shared hosting environment and don't have direct SSH or shell access.

I've seen this sentiment a few times now, so this seems like a good time to point out that you do not need SSH access to your server in order to use Composer. In fact, I don't run Composer on a live server (regardless of whether it's using shared hosting) and it's not on my list of things to do in the near future.

What you do need is a process where you handle your Composer dependencies on your own computer where you have PHP running.

He gives two possible solutions to the problem: either commit your dependencies or create some kind of build script that can execute the Composer install for you on deploy. He gives details on both of these solutions including the process for installing the dependencies with an automated FTP script (run at deploy rather than committed).

On the Acquia blog there's a recent post from Ryan Weaver from KnpLabs, well known for his contributions to the Symfony2 framework. In his post he suggests that the future of PHP is "shared power tools", less around the monolithic frameworks or installable software and more about the combinations of small pieces of code doing exactly what they need and nothing more.

[Things like Drupal, Joomla and WordPress are] painstakingly thought about and solved the same problems from scratch. And despite that, the results were incredible. How? Because they leveraged the sheer size and passion of their respective PHP communities. But it makes me wonder: what crazy things could we build if we worked together? Fortunately, we're on our way to finding that out. The PHP world is transforming and the individual armies and empires are blurring together.

He talks about how PHP developers should stop fighting the same battles and start working together using existing libraries to solve problems. He points out that applications, even the big names, are becoming more and more modular. Even Drupal has recently made the move to include Symfony packages for some of its functionality (other examples are given too). He also talks about "developer experience" in using these tools, what Symfony is doing to help it and how building on these and other components is essentially "standing on the shoulders of giants" to solve problems easier, faster and with better quality code.

On the SitePoint PHP blog today Aurelio De Rosa makes some recommendations about handing gettext translations on shared hosting. The problem with shared hosting is the need to reset the web server (Apache) to get it to read the updated translation files. His workarounds uses an external script that can dynamically pull in the latest translations without the restart.`

For serious translations we can use Gettext. This approach enables us to have different files for every targeted language which helps in maintaining separation between the business logic, the presentation layer, and the translations (which we can see as an add-on of the presentation layer). With Gettext, we can parallelize the process because while we’re working on some features of the website, translators can still work on translations using software like gettext functionality to set the current language and extract a "HELLO_WORLD" string. He then moves on to the use of the Audero Shared Gettext library. This library creates a "mirror" of the translation file requested and forces those updates into the current domain. Code examples of its use are included showing a basic pull and merge process.

In this recent post to his site, Phil Bennett shares some thoughts about the PHP-FIG, the standards they're proposing and how the shares interfaces might help reduce dependencies in framework-based applications.

[Frameworks] come in several different flavours that all have huge advantages, but also a few disadvantages. Over engineered (because their popularity demands that they be), updated too often, not updated enough. If you decide for example to update your application from using Zend Framework 1 to using Zend Framework 2, this will more than likely require, at least in part, a re-write of your code. This makes scalability difficult.

He talks some about the PSRs that the PHP-FIG group has proposed including the PSR-3 logging interface structure. He points out that, by having this same structure, it makes injecting dependencies easy while still leaving the actual functionality open to interpretation. He also suggests that maybe a framework isn't the right choice for all applications and that possibly using a collection of libraries, tied together by the PSR standards, could be a better answer.

Paul Jones has written up a response to Matthew Weier O'Phinney's recent post on shared interfaces and the PHP-FIG. In it he talks about the PHP-FIG group itself and specific references back to the original post.

He mentions the ideas of "new thinking" and the limitations that standardized interfaces might try to impose on an application:

One is able to imagine reasons why having shared interfaces of the kind described above is in opposition to, or at best orthogonal to, better development practices and greater innovation across PHP land. Even so, I assert that shared interfaces as described, while maybe preventing an imaginable ideal in theory, instead promote an actual good in practice.

Matthew Weier O'Phinney responded with some of his own comments and correcting some of the misinterpretation of his original comments.

In his most recent post Matthew Weier O'Phinney (lead on the Zend Framework project) takes a look at the PHP Interoperability Group (php-fig) and some recent discussions that have come up about shared interfaces for things like logging and caching.

A little over a year ago, there was a new push by a number of folks wanting to do more. Paul Jones did a remarkable job of spearheading the next two standards, which centered around coding style. [...] And this is when we started seeing proposals surface for shared interfaces, first around caching, and now around logging (though the latter is the first up for vote).

He talks a bit about shared interfaces - what they are and what kind of problem they aim to solve - and how he's not sure he "buys into them". He notes that "sharing is good, developing solutions is better" and stresses making it easier to operate with each other and not worry so much about standardized interfaces.

He's found a few problems with the concepts behind them like the Not Invented Here (NIH) idea they promote and that there's not really just a single solution to these kinds of problems ("space for multiple implementations"). He suggests an alternative to the idea of these shared interfaces - bridges/adapters. He illustrates this idea with some code showing the implementation of a "CacheInterface" and a "FrameworkACache" adapter that wraps the functionality of a "CacheItem" class that might be internal to your application already.

On the PHP-Security.net blog today there's a new post showing how to get the latest version of the Suhosin security patch for PHP installed.

With the recently released PHP 5.4, the Suhosin patch and extension were removed from many Linux distribution packages (i.e., Debian et al.) and until three weeks ago, there was no possibility to compile and run the Suhosin extension under PHP 5.4. This little howto shall serve as installation instruction for Debian Wheezy users - your mileage may vary. I blogged about this here.

They start with the apt-get commands to install the latest PHP5 for your distribution (yum commands are similar, of course) and includes the location to download the latest Suhosin version from Stefan Esser's github account. Unpack it, compile and "phpize" it and if all goes well, you should have a shared module built and ready for use.