In a recent post to the Laravel News site, there's a post showing how to make use of a PHP package for storing and retrieving global settings that are then store them locally on the filesystem as a JSON-formatted document.

In applications it is often useful to have a way to store some global settings. These settings are not related to a specific model, such as a user, but to the system as a whole. You can achieve this with Eloquent, of course, but I never felt that was the right approach given you are saving non-relational data in a relational system. I found Spatie’s Valuestore package to be the perfect fit for creating a settings repository for an application.

The package will take your settings and store them as a JSON file on the local filesystem. Let’s use the example of having a banner notification at the top of your application. The banner notification is visible on every page and an admin can update the text it contains.

The tutorial walks you through the installation of the package via Composer and how to create the initial Valuestore instance, pointing it to a file on the local disk. It includes sample code showing how to push and pull values from the store including in your Blade templates. The tutorial also shows the binding of the store to the container and how to define it as a global helper.

For the WordPress users out there, the RIPSTech.com blog has posted an invaluable "cheat sheet" sharing details on securing your configuration to prevent exploits and other issues down the line.

WordPress is the most frequently installed web application in the world. The system is operated not only by experienced developers but also by beginners. In this blog post, we summarize what to look out for when configuring your WordPress installation’s security.

In our series about misconfigurations of PHP frameworks, we have investigated Symfony, a very versatile and modular framework. Due to the enormous distribution and the multitude of plugins, WordPress is also a very popular target for attackers. This cheat sheet focuses on the wp-config.php file and highlights important settings to check when configuring your secure WordPress installation.

Suggestions made in the guide cover values involving: debugging, database credentials, keys/salts, database repair, external requests and many more. The post provides examples for each of the settings and a recommended value to make it easy to drop in the changes and harden your WordPress installation.

On his site Sameer Borate gives you a quick tutorial on how to migrate your WordPress site to HTTPS to help secure the communications between it and your users.

Finally, after much deliberation, I decided to move my blog to https. For the past few months I had encountered articles pointing that google gives a higher ranking for sites served over https. I had decided against https as I was afraid it may slow down by blog. However, the [a message about Chrome's HTTP/HTTPS support] from google forced me to take the issue seriously and finally move to https.

[...] Luckily during the same time Godaddy was offering SSL certificates at a discounted price. So taking this as a sign I bought the SSL certificate and moved my blog to HTTPS. Surprisingly installing SSL on Godaddy was a breeze. There was no configuration involved and the SSL certificate was applied within a few minutes.

He assumes that you know how to get the certificate installed, so that part isn't covered. He does cover the shift of the WordPress site over including changes that'll need to be made to web server and WordPress application configurations. He ends the post briefly talking about any speed difference he saw with the site (hint: not much).

If you're a Slim framework user you should check out the latest post on Rob Allen's site covering all things configuration in using the framework and it's simple configuration handling.

Configuration in Slim Framework is nice and simple: the App's constructor takes a configuration array for the DI container.

He shows how to pass in the configuration as a optional constructor parameter on the main application, including a settings value containing some of the common options. These include the displayErrorDetails flag to show/hide detailed error messages and a logger setup (in his example Monolog). He also shows how to:

• get settings from the configuration
• use a separate file for the configuration
• using a .env configuration file
• combining multiple configuration files

He includes code examples for each of these cases as well as a method for using a non-array structure (like YAML or XML) via the ZendConfig component.

The SitePoint PHP blog continues their series looking at Drupal 8 with this new article from Daniel Sipos about third-party settings and pseudo-fields. Part one of the series can be found here

In the first installment of this series we started our journey towards creating some simple but powerful functionality. The goal we set was to have the possibility to load a form on each node page and to be able to choose which form type should be used on the different node bundles. [...] It follows to see how we can configure the core node types to use one of the plugins defined on the site and how to render the relevant form when viewing the node. But first, in order to have something to work with, let’s create our first ReusableForm plugin that uses a very simple form.

He starts back in with the creation of a first simple plugin to handle the form created in the previous part of the series, assigning the form to it via annotations. He then configures the node entities to be able to use the plugin via the services YAML configuration file. He then updates the .module with a function for altering node details and an entity builder. He updates the schema definition to be able to show the form and, finally, render the form out to the view with the assigned node entity types.

On the SitePoint PHP blog today there's a new tutorial posted that gets into the details on one of the powerful (and most used) components of the Symfony framework, the Router, and how to interact with it via annotations. Symfony's route annotations allow you to define functionality at the controller level or via a YAML configuration file.

When you download the Standard Symfony 2 Distribution, it includes an interesting bundle named SensioFrameworkExtraBundle which implements a lot of great stuff, especially the opportunity to use annotations directly within your controllers. The idea behind this article is not to convice developers to embrace this way of doing, but to point the finger at an alternative method to easily configure controllers. Keep in mind that there is no magic recipe, it depends on what you need in each specific scenario. Symfony 2 implements a strong built-in component to manage all the routes of an application: the Routing Component. Basically, a route maps a URL to a controller action.

His example sets up a simple blog and compares the two ways of configuring the routing: one side putting it all in the YAML configuration and the other in the controller docblocks (annotations) themselves. He adds a base page for showing the listing of posts and a single article route, complete with slugs. He also shows how to add in some additional configuration handling to do things like set default values, making things required and enforcing the HTTP method on the request (GET, POST, PUT, etc)

In the latest post to his site, Ruslan Yakushev looks at some simple ways you can debug your PHP-based applications running on a Windows Azure platform.

The need to diagnose and troubleshoot application’s failures often comes up during deployment to a hosting environment. Some configuration settings in hosting server may differ from what application expects. Often it is not as easy to figure out the cause of the problem in a hosting environment as it is on a development machine. I found the following techniques useful when troubleshooting errors in PHP applications hosted in Windows Azure Web Sites.

He shares seven different tips, some pretty simple, others a bit more difficult requiring other software to be up and working:

• Using phpinfo()
• Checking the wincache settings
• Looking at your error logs
• Turning on the display_errors setting
• Turning on HTTP logging, detailed errors and failed request tracking in the control panel
• Using XDebug
• Getting the statistics for your ClearDB instance

In this quick post to his blog Mattias Geniar looks at three different Apache flags you can use in your configuration/.htaccess files to set various things in your PHP environment.

Back in 2009 there was a bug in the php_admin_value implementation before PHP 5.2.6. Since then, everything should run smoothly again. However, I find there's still a lot of confusion on when to use php_value, php_admin_value, php_flag and php_admin_flag. So I'll see if we can clear some of that.

He compares the three php_* flags you can use to set different kinds of values - "php_flag" for boolean operations, "php_admin_flag" (similar, but only in the vhost config) and the "php_value" that can be used for everything else, including overriding some settings in your php.ini.

Brian Swan has a new post today looking at how you can update some PHP settings in your Windows Azure instance - an alternative to redeploying your every time your php.ini file might need an update.

I came across this question on Twitter last week: "How can I turn display_errors on for an application that is running in Windows Azure?" I have to admit that I was stumped. The only thing I could think of was to re-deploy the application with an updated php.ini file. But, I happened to mention this question to Ben Lobaugh who suggested a very simple idea: Store your PHP settings in some durable store external to your application as key-value pairs, then loop through the settings and update them with the ini_set function when a page loads.

He puts a big disclaimer on his suggestion, noting that it's "a hack and only a hack" and can be useful for someone still learning how to work with Azure and deployment. He shows how to use a Table storage to save the values and make them easier for the application to grab at runtime. Using the tools from their SDK, fetching and setting those values is a simple process. An idea like this, while convenient, could potentially cause performance issues down the line, do be careful with this recommendation (and be sure to load test).

PHPit.net is back again today with yet another great tutorial. This time, they help you create a class to manage the settings for your application that not only supports plain-text, but INI, XML, and YAML formats as well.

A config.php or a settings.xml file is a very common thing for most PHP scripts, and it's usually where all the script settings (e.g. database information) are stored. The easiest way is to simply use a simple PHP script as a config file, but this may not be the best way, and it's certainly not the most user-friendly way.

In this tutorial we'll have a look at creating a Settings class which can handle any type of config format. I'll take you through the steps necessary to handle four different formats (PHP, INI, XML and YAML), but it's very easy to add more formats.

To start, they build the base class before quickly adding the get() and load() functions to pull in the external content. First on the list, they extend the base and make a pure PHP implementation holding the settings. Following that, they move on to the INI format, using PHP's parse_ini_file function to make it simple.

Last but not least, they venture into something a bit more complex - working with XML and the YAML formats to create this simple, handy tool.