File Storage

This feature is mainly for developers who want to store their settings in files rather than in the database. Files are easy to transfer around, especially when using a version control system (VSC) like Git. Sharing the same settings with your team or pushing them to your (client’s) website is a breeze when using file storage. Even if you are not a developer, it’s not that hard. We like to keep things elegant and simple.

TL;DR

• With File Storage, you store your settings as files and not in the database
• Git (or any VSC) will pick up the changes
• You can use i18n for your settings by supplying a text-domain
• You can make your settings “readable only” once you push them to another environment
• You have fine-grained control over which settings will be stored as files and which will be stored in the database
• You can migrate your database to File Storage with a single line of code
• Our excellent documentation will get you started quickly

How does it work?

In our documentation you can see exactly how it works, but here we’ll explain the concept a bit further.

The basic idea is that every screen you create becomes a file instead of a record in the database. Every time you create or update an overview page or Table View, a file is also created or updated.

Setting up File Storage uses a custom WordPress filter. With this simple filter, where you return the folder where the files are to be stored, you are up and running:

add_filter( 'acp/storage/file/directory', function() {
	return get_stylesheet_directory() . '/acp-settings';
} );

We also have a more advanced filter that lets you set up File Storage with fine-grained control. By supplying one or more rules, you decide if a screen is stored as a file or in the database and where a file is stored. A rule can be anything that asserts to true or false. We have supplied a few handy rules already, but creating your own rules is very simple. As you might have implied: files and the database can be used together.

The advanced filter also lets you decide if you want files to be writable. This is great when you want to provide some as-is functionality alongside a plugin or a theme. Users can still make a copy of these settings and make changes, but you can always revert to your original settings.

And lastly, starting from version 6.3.0, File Storage will support i18n and the ability to save global segments. With these two added features, File Storage will be an invaluable asset in the toolbelt for developers who rely on things like Git and Composer in their workflow.