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.

The TutsPlus.com site has posted a tutorial today showing you how to use the "Store" functionality in Mailgun from your PHP application to temporarily handle your incoming emails.

In today's episode, Mailgun stepped in to sponsor a tutorial about how I integrated its message routing and Store() API to handle replies from users.

For example, when people receive meeting requests from others with Meeting Planner, they may just choose to reply and send a note like they would to a typical email thread. [...] Sounds complicated, but one of Meeting Planner's goals is to reduce the back and forth emails between people about planning and consolidate real-time changes into fewer notifications.

The start by introducing the Mailgun service and, more specifically, the Store() offering it provides. He uses a Yii2 framework based application to show the integration. Once the MX (mail) records are set up correctly it can then hook back in to your mail servers or web application. The code is included to make the migration to hold the notification info, make the POST request back to the application and use background process to handle the mail processing.

The SitePoint PHP blog has posted the next article in their "eBay Trading API" tutorial series today. In this new tutorial they show you how to configure your store's settings.

In part 1, we explained the different parts of eBay’s developer dashboard and configured our test application. We also created our database. Now we’re ready to create a project. In this part, we’ll focus on store settings. In part 3, we’ll add new products to our store.

They include the "composer.json" contents you'll need to install all of the libraries they'll use for the tutorial. With those installed they start in on the code, creating a basic Slim application that uses Twig views and some custom configuration options. Then he starts in on the classes, creating an "Ebay" class to handle the application settings and creating a "post" method to handle the API request. He adds in a few other helper methods and builds a database object/query to get the application details from the database. Next up are the templates for the main page and the controller to handle the default, session and token requests. He adds in some additional route configurations, makes a "view action" for the store settings and to request the user preferences from the API.

Oscar Merida has a recent post to his blog about using the bcrypt functionality to more securely store the password information for your application's users.

The linkedin password breach highlighted once again the risks associated with storing user passwords. I hope you are not still storing passwords in the clear and are using a one-way salted hash before storing them. But, the algorithm you choose to use is also important. [...] The choice, at the moment, seems to come down to SHA512 versus Bcrypt encryption.

[...] I wanted to switch one of my personal apps to use bcrypt, which on php means using Blowfish encryption via the crypt() function. There's no shortage of classes and examples for using bcrypts to hash a string. But I didn't find anything that outlined how to setup a database table to store usernames and passwords, salt and store passwords, and then verify a login request.

He shows you how to set up a simple "users" table and the code for a "save_user" method that takes in the username/password and generates a salt and calls crypt on it with the Blowfish prefix on the string ($2a$). His login check function ("validate_user") then takes the user's input, does the same hashing and checks the result.

Evert Pot has a quick new post to his blog today talking about how to push encrypted information into a cookie for storage.

There have been a couple of approaches I've been considering [to replace sessions being stored in the database], one of which is simply storing all the information in a browser cookie. First I want to make clear I don't necessarily condone this. The reason I'm writing this post, is because I'm hoping for some more community feedback. Is this a really bad idea? I would love to know.

He includes some code to make it happen - a class that uses the hash_hmac function and a SHA1 encryption type (along with a salt) to convert the information into a string that can be (relatively) safely stored in a cookie. Be sure to read the comments for more opinions on the method.

Alvaro Videla has submitted a new post he's written up combining PHP and Erlang yet again, but this time he's using it to just store key/value pairs rather than for session data.

In this post I want to show you some of the neat things that can be done with the PHP-Erlang Bridge extension: A Key Value Store. Erlang comes packed with a Key Value store in the form of the ETS module. This is database is pretty fast and efficient for storing the Erlang terms in memory.

He tried a proof of concept to see how well the system would respond and was able to push over 150k items into the storage in one second. Sample code and instructions on getting the bridge working are included in the post.

On Till Klampaeckel's blog this recent post shows you how to (quick and easy) set up multiple Magento stores on different domains with the same codebase.

Multiple stores is probably the killer feature of the Magento Commerce store. It enables the needy to manage multiple stores through a single interface. Your very own mall in a box. It's also a management/deployment nightmaredream come true. A single piece of software powering multiple websites.

He sets up his directory structure and shows how to alias certain directories to ones in the local document root so that the application will find things correctly. Drop in a custom index.php "bootstrap" file to run the application and you should be all set.

David Goodwin has a suggestion for those developers that think storing objects in a database is a good idea - don't do it!

Short answer: DO NOT DO IT. Longer answer:....I hate seeing serialized PHP objects within a database.

Some of his reasons include:

• It's difficult to index/search - you'll probably need to use a regexp.
• PHP Specific - good luck doing much with the data in a.n.other language
• If the objects are large, you're likely to have a text or a blob field - this will suck from a performance point of view (at least in MySQL)
• Why bother storing serialized objects in a database - surely to the filesystem would be better?

Several opinions are expressed in the comments including some that agree with David and some that still defend the idea.

Jani Hartikainen has posted the third part of his series looking at access control and the Zend_Acl component of the Zend Framework. This article focuses on creating and storing dynamic ACL lists in a database.

As we have previously looked at ACLs which are hardcoded, we will now look at building a "dynamic" ACL. Previously shown "static" ACLs are good for quick and simple sites, but when you actually require the ability for administrators to define access rights on the fly using an admin panel, they quickly lose their usefulness.

Dynamic lists provide more flexibility in handling the access control of your site - it allows you to only pull what you need (just that user) when you need it. His method uses an ACL factory class to create the Zend_Acl objects for each request. He includes an example of protecting an application used to serve out files to visitors. You can download the code if you'd like to mess around with it yourself.

Etienne Kneuss has posted a look at using the SplObjectStorage functionality of the Standard PHP Library as a safe place to tuck away and protect your objects.

In PHP, you basically need two things to safely identify an object: a object index, the handle, and the class handlers which is how the object will react internally. This set of handlers is actually a pointer, and since disclosing valid pointers is not something that should be done, spl_object_hash is simply providing a MD5 hash of those two values concatenated.

Since arrays are hashed when they are created as well, your script is doubling the amount of work it has to do behind the scenes. Instead, Etienne suggests that you use a SplObjectStorage object instead of an array to keep objects inside. The unique identifier for it is then used directly (instead of rehashed, leaving it open for possible referencing collisions) to reference the object.