Loïc Chardonne has kicked off a new series of posts on his site that talk about doing "Symfony Differently" and some things to consider/change to increase your Symfony application's performance.

Symfony is an amazing HTTP framework which powers high traffic websites. Performance shouldn't be a concern when first creating a website, because between the time it is launched and the time it actually has a high traffic many things that we didn't expect in the first days will happen: requirements will change, user behavior will change, even the team can change.

Optimizing applications has an impact over maintenance, and making it harder to change right from the beginning might not be the best option. However when the need of performance actually arises, we need to tackle it. This series of articles is about this specific moment, and how to tackle it in a pragmatic way.

He starts with a basic project (Acme) and works through the process of adding a new feature to it: buying an item. He talks about the team they have to work with and the architecture of his sample application (a frontend application mostly). He then works through the data structure and flow of the new feature and other functionality that should be included. He ends the post with a bit of a wrap-up of this first part and talks about the next part in the series where the application will actually be bootstrapped.

The Symfony2 security component has the fame of being one of the most complex in the framework. I tend to believe that's partially true, not because the component is really that complex, but because there are (really) a lot of concepts involved and it may be difficult to understand them all at once and have a clear vision as a whole.

[...] Going back to the Symfony2 security component, the point is that I found out difficult at first glance to get a clear idea of what is going on behind the scenes and what I need to write to create a custom authentication mechanism. So in this post I will try to collect few interesting resources that helped me understanding it better and a graph I drawn to resume what I learned.

He provides a good list to some of the other resources that helped him along the way including several blog posts and links to the Symfony "cookbooks" about creating custom providers. He also shares a graph showing the full flow of the Symfony authentication process including commentary about each step.

On the Bigcommerce Engineering blog there's a new post sharing a few tips for memory optimization in your PHP applications. This includes tips you can implement at a code level without too many changes to the server or the need for external services.

Lately, I’ve been working on optimizing the memory of some of our backend PHP applications and wanted to share some of the tricks that I have come across, especially dealing with large set of data using PHP.

Each of their tips includes code to illustrate the technique:

Always cap your internal in-memory caching

Use layered caching

(Freeing) DB Resources

Free large blocks of memory

Some of the examples include output from the scripts showing the reduction (or non-growth) of the peak memory usage of the script.

PHP has had many reputations over the years, but being insecure as a language never really was one of them. The core team, all its faults notwithstanding, is rather quick in pouncing on all security matters, and updating PHP to the latest version will often allay all worries. But the end users, such as we are, tend to mess things up. We don’t update, we use outdated packages or packages with holes in them we’re not aware of, we use ancient extensions… we expose ourselves to risk in some truly creative ways.

Some of the things mentioned include:

Keeping your PHP up to date

Adopt HTTPS

Secure your PHP

Stay on the Right Way

Avoid Bad Packages

Dodge common mistakes

Use Virtualization

Each section comes with a description and plenty of links to point you in a good direction and get you started off right for 2015.

Phil Sturgeon has an interesting post (with plenty of comments following it) about what he calls the "tribal framework mindset" - basically that certain technologies can provide a siloing effect on developers rather than engaging them as a part of the PHP community as a whole. One community centered around the Laravel framework sparked the post.

As much as I understand pushing the "Laravel Community", content, blogs, etc, can we stop this soloing of efforts and be a PHP community? [...] It should still have made sense. [...] Well, I thought so at least until I had a myriad of bizarre responses from people (mostly the well-known Laravel names) defending and picking issue with things I said, assuming instead of saying something logical I must have meant something moronic. That is rather offensive to me, so let's explain it for them.

He goes on to break it down into four different topics and summarizes how the "framework versus general PHP" point fits in - packages and functionality, developers and how they label themselves and books/other resources. He finishes off the post with a look at the "morals" behind it all and how, due to some of the "tribal bullshit" he's seen (even in his own CodeIgniter experience), developers are siloing into groups when really they should be a part of the community as a whole.

In a new post to his site Lukas Smith wonders what's next for Symfony2, the popular PHP framework. Rather than the actual framework, though, he looks at the framework community and wonders where they should direct their attention.

Avid readers of my blog might have noticed a theme in recent blog posts. A while ago I noted that core developers of the early days have become a lot less active. Then I posted about the need to start working on higher level code to make Symfony2 more rapid development friendly. Following this post I blogged about what is missing to make Symfony2 truly great for building REST APIs. Now last evening at DrupalCamp Vienna I was asked what is there left to do for the Symfony2 community and it didn't take me long to think of an answer: Bundles!

He talks about some of the current ecosystem around the framework's major bundles and wonders where people should be focusing. Are there bundles that should be worked on more, building up features and providing a more solid core group of developers (than maybe one or two)?

On the SitePoint PHP blog today Bruno Skvorc has posted some tips to helping you become a "PHP professional" and advance your skills and, potentially, your career in web application development.

When reading various PHP related blogs, Quora questions, Google+ communities, newsletters and magazines, I often notice extreme polarization of skill. Questions are either at the "How do I connect to a MySQL database?" level or something in the range of "How do I best scale my mailing system to send over one million emails per hour without introducing a new server?" I personally distinguish between 4 distinct levels of PHP prowess (likely applicable to any language/profession): beginner, intermediate, professional and elite.

He starts by looking at "the extremes" - the absolute beginners and the highly experienced professionals that have spent a lot of time "honing their skill". Somewhere in the middle are the intermediate developers. These are the ones he focuses on for the rest of the article, providing them with the knowledge and resource to advance. His recommendations include:

Abandon spaghetti code

Learn to set up your own PHP environment

Exercise best practices early

Read

Find a buddy/mentor

There's a description for each one - and several more - with links to resources and other information to get more detail.

The World-Wide Web offers more PHP performance tips than can be comfortably discussed in one article, so the following is merely a list that can be used for reference purposes. The tips are divided into categories to group similar things together and make it easier to find what we need. The author’s search for tips was extensive, but completeness still cannot be guaranteed.These tips fall into category #3.1 (the server executes a script) in the taxonomy of tips that we have been working with.Because of the sheer volume, these tips have not been tested. The reader is expected to test them in his own production environment before relying on them. This is not unreasonable, though, because the value of most tips depends on the unique environment within which PHP operates.