In a new post to his site Matthias Noback shares some of his recent experience working with a multi-tenant application and the current "contexts" that exist during the user's session. In the most he makes some suggestions about how to generate this context on each request without having to resort to a "data clumping" approach.

In the beginning we start out with a framework that has some authentication functionality built-in. We can get the "current user" from the session, or from some other session-based object. We'll also need the "current company" (or the "current organization") of which the current user is a member.

In the web controller, we take this information out of the session (which we can possibly reach through the "request" object passed to the controller action as an argument). Then we start doing the work; making queries, making changes, sending mails, etc. All on behalf of the current user and the current organization. [...] Soon this starts to feel like a code smell known as a Data Clump: the same data hanging around together.

He offers a few different steps to follow to make sure you're correctly implementing this functionality and not violating the SRP (Single Responsibility Principle):

• Injecting the session
• The Context class
• Passing contextual values on a need-to-know basis
• Fetching more data when needed

For each item on the list there's a paragraph or two explaining the changes and functionality with code examples included where necessary for illustration.

Matthias Noback has posted a continuation of his previous article covering unary call sites and interfaces with this new tutorial with a way to reduce these call sites by making effective use of dependency injection and passing values with the correct context.

While reading David West's excellent book "Object Thinking", I stumbled across an interesting quote from David Parnas on the programming method that most of us use by default [about the process a machine uses to execute code]. It may seem like a very logical thing to do. And it's what I've seen myself and many other programmers do: "How do we implement this feature?"

[...] I described one situation in a previous article about read models, where I realized that we often try to answer many different questions by querying one and the same model (which is also the write model). By splitting write from read, we end up with a more flexible design.

The same goes for introducing interfaces, to achieve dependency inversion. We do a little extra work, but we thereby allow ourselves to get rid of a bit of "computer think".

He goes on to talk about singletons, service locators and registries and how dealing with them can get complex relatively quickly. He then shares a few possible solutions in the form of dependency injection and passing in the items needed for context rather than pulling them from another object. He ends the post with a summary of the combination of these two methods, showing how they can reduce the number of overall "call sites" for pieces of functionality in your application.

On his Medium.com site Jeff Madsen shows you how to use contexts in the PhpStorm IDE to switch between environments or current work using a more streamlined process.

Switching context is a pain.

Not just because you need to mentally switch the complex web of ideas in your head. Think about all the physical files on different git branches you have to remember in order to answer a “quick question about task #123”. [...] PhpStorm has a lot of great context links and shortcuts to help you navigate among all these, but it is still a royal pain whenever you need to put one set of files aside and work in a different area of the codebase.

[...] When I finished something and pushed it up for review if there was even a small request to change a default or label I had to reopen the branch and track down the correct files where the work was done. How could I turn that all into a single, easy step?

Enter Contexts and Tasks!

He starts off by defining what a "context" is in the world of PhpStorm - a group of open files with a name attached - and how they can be created/saved inside the IDE. Next is the idea of "tasks" that help with performing operations and relating them to contexts and groupings of files. He then shows how to switch between tasks related to a certain feature and how to close it out when you're done.

In a post to his site Benjamin Eberlei looks at global state in PHP using something called "context objects" and how they can be used as an alternative to true global state.

Global State is considered bad for maintainability of software. Side effects on global state can cause a very nasty class of bugs. Context objects are one flavour of global state. For example, I remember that Symfony1 had a particularly nasty context object that was a global singleton containing references to very many services of the framework.

As with every concept in programming, there are no absolute truths though and there are many use-cases where context objects make sense. This blog posts tries to explain my reasons for using context objects.

He starts by getting everyone on the same page by defining a context - the "circumstances in which something can be fully understood". He then moves into the world of context objects, talking about how they encapsulate the information other objects need to execute. They're essentially "container" objects that allow for more control that something like the normal PHP superglobals. From there he helps you define what kind of context objects you might need in your application and provides a real-world example from his own experience at Tideways.

In a post to his site Robert Basic has shared some helpful plugins for PHP developers using Vim as their primary editor. These plugins not only help you jump around in your code but get more context on where you're at.

One thing I was missing for a long time in Vim is to be able to "jump to definition" in an easy and painless way. The other thing I wanted to improve is to be able to tell easily where am I actually in the code base; to see the current class and method name of wherever the cursor was.

With a bit of googling and poking around, I finally came up with a perfect combo of 5 plugins (yep, five!) that enables me to do both, and a little bit of extra.

He shows examples of using three different things he wanted to be able to do when working in his code and the plugins that satisfy each:

• Generating and managing tag files for the code (Gutentags)
• Jumping around to definitions (CtrlP)
• Providing context on the current class and method name (tagbar+tagbar-phpctags+lightline and phpctags

One line examples are included showing how to configure them with your current Vim use.

Continuing on their series about context in Laravel applications, the Culttt.com blog has posted the next part talking about setting the context of the application. In this case the term "context" relates to the "operating environment" the request is happening in (not to be confused with the environment, things like the server/software installed).

Last week we looked at managing context in a Laravel application. Context is a very important aspect of a web application as this foundational structure will be relied upon for almost every piece of code. Setting the context usually involves checking against the business rules of the application.

For example, does the current user have access to this group? Does the current task belong to this project? Can this user create a new post in this thread? These kind of foundational business rules need to be addressed whenever a request enters the application.

He starts by talking about the importance of the URL the user is requesting, pointing out that it should be both useful to identify the resource and provide a "sense of hierarchy" for the application. He then shows how to, using the "Guard" handling in Laravel, to define the context and ensure that the user is operating within an allowed context. Full code is included to set up the system and creating the objects to resolve the group and request information into something useful.

Rob Allen has a quick post to his site talking about some of the improved error handling that's been updated in the latest version of the Slim microframework to help make reporting issues easier in multiple contexts.

From RC1 of Slim 3, we have improved our error handling. We've always had error handling for HTML so that when an exception occurs, you get a nice error page [...] However, if you're writing an API that sends and expects JSON, then it still sends back HTML. [...] At least we set the right Content-Type and status code! However, this isn't really good enough. We should send back JSON if the client has asked for JSON. Until RC1, the only way to do this was to register your own error handler.

With Slim 3 the framework handles things more correctly based on the value of the "Accept" header sent along with the request. This value is checked and, if it references JSON or XML, the error message is translated either giving the default output or reporting back for the "notFound" and "notAllowed" error types.

The Paragon Initiative has posted a new tutorial that wants to provide you with everything you need to know about preventing cross-site scripting in PHP applications.

Cross-Site Scripting (abbreviated as XSS) is a class of security vulnerability whereby an attacker manages to use a website to deliver a potentially malicious JavaScript payload to an end user. XSS vulnerabilities are very common in web applications. They're a special case of code injection attack; except where SQL injection, local/remote file inclusion, and OS command injection target the server, XSS exclusively targets the users of a website.

[...] Cross-Site Scripting represents an asymmetric in the security landscape. They're incredibly easy for attackers to exploit, but XSS mitigation can become a rabbit hole of complexity depending on your project's requirements.

He introduces the concept of cross-site scripting (XSS) for those new to the term and provides a brief "mitigation guide" for those wanting to jump to the end. He then gets into some examples of what a XSS vulnerability could look like, both stored and reflected and provides the "quick and dirty" method for preventing them. He also mentions some tips in implementing your solution including avoiding HTML in your data if at all possible. He goes on to talk about the use of HTMLPurifier to prevent attacks, context-sensitive escaping (HTML vs JS vs CSS) and some of the browser-level features that help prevent XSS for the user.

The ServerGrove blog has posted a new tutorial with a selection of useful command line tools to help you in working with your PHP applications. None of them are PHP specific but are Unix-based commands that can help in every day development.

Linux provides a lot of interesting command-line tools that we can use when working with PHP projects. In this post we give you some useful commands.

They include examples of commands that can help with:

• Find all PHP files in the current directory
• Check the syntax of all PHP files in the current directory
• Get the size of each Composer dependency
• Find suspicious PHP files
• Find files with abstract classes
• List PHP settings for the xdebug extension
• Find empty files and/or directories
• List files currently open by a PHP process

As mentioned, most of the tools themselves are not PHP specific but these example commands do relate to things that are more in a PHP context.

In an interesting new post to his site Matthew Setter wonders if an IDE like PHPStorm can be replaced by VIM, a standard in the editor community for decades.

Is it reasonable, even practical, to expect that a 30 year old application can match a modern one? Is it conceivable to be able to code as well using VIM, said 30 year old application, as I can in PhpStorm, with all the IntelliSense-lead functionality PhpStorm offers?

He starts with some of his recent experience with the editor and some of the things he's (happily) found it can do he didn't know before. He includes a screenshot of a multi-pane view, explains what each is and what he can do with them. He points out that this example is Markdown documents but it can just as easily be used for code too. Finally he talks about the subject any PHPStorm user wants to know about, the IntelliSense functionality. Unfortunately, while there are some tools he mentions that can do similar things, they don't provide the context PHPStorm can deliver.

He ends the post with an interesting question: is IntelliSense the right approach? He wonders if having more context is a better answer rather than just the auto-complete handling IntelliSense offers.