File system storage

About the feature

By default, Layouts and Post Selection are stored in the database. The File system storage allows you to store Layouts and Post Selection data as files inside your theme and has the following advantages over the Database method:

• IDE compatible You can amend code in your favorite IDE

• GIT compatible You can track changes using Git or another tool. In addition, you can automatically delivery changes to Live

• Sass and TypeScript compatible You can extend the default CSS to Sass for JS to TypeScript

• Tailwind support You can use Tailwind in the templates

Please note that this is a storage-only option, and for creating and configuring Layouts and Post Selections, you still need to use the plugin's user interface.

Note: this feature is UI-compatible, which means after activating, you can amend code in both ways, using your IDE or the on-site editor within your Layouts or Post Selections.

How it works

Layouts and Post Selections are Custom Post Types (CPTs), and their items store their settings as JSON in the "post_content" field of the "wp_posts" table (for better performance). When File System (FS) storage is enabled, Layout and Post Selection settings are stored inside your theme folder. While their settings are still stored as JSON, they exclude all code-related fields, which are converted into separate files to make them easily editable.

Note: When you enable File System storage, you still create and configure Layouts and Post Selections using the plugin's UI. The plugin creates posts for them but stores their settings inside your theme folder instead of the "post_content" field in the database. This allows you to benefit from the UI during creation and configuration and take advantage of your IDE when editing.

How to use it

You can enable and disable the File system storage in the plugin's Settings.

Folders structure

When you enable the File System Storage option, Advanced Views creates an "advanced-views" folder inside your active theme directory. This folder contains the following items:

"advanced-views" folder

This folder serves as the parent folder for all Layouts and Post Selections. Every Layout and Post Selection from the Advanced Views plugin has a dedicated sub folder.

"layouts" folder

Each Layout folder follows a specific naming structure: "layout-name_unique-id." For example, if you have a Layout with the title "ACF fields" and the unique ID "651d5d75bfdf2," then the folder name will be "acf-fields_651d5d75bfdf2."

Including the title in the folder name makes it easier to navigate without having to search for the specific ID. You don't need to worry about keeping the folder name up-to-date because Advanced Views automatically renames the folder when you change the Layout name in the user interface.

Layout folder files

You can find information about the files inside the Layout folder below:

File name	File description	Related UI field
style.css	CSS code of the current Layout	CSS Code (CSS & JS tab)
style.scss (optional)	Sass code* (see the related chapter of this page)	-
script.js	JS code of the current Layout	JS Code (CSS & JS tab)
script.ts (optional)	TypeScript code* (see the related chapter of this page)
view.php	Custom Data snippet of the current Layout (note: in Pro only)	Custom Data (Template tab)
custom [.twig] [.blade.php]	Custom template of the current Layout	Custom template (Template tab)
default [.twig] [.blade.php]	Default template of the current Layout (note: for preview purposes only)	Default template (Template tab)
data.json	settings of the current Layout	-
multilingual.php	multilingual stubs	-
links.md	Edit Layout link (allows to open the Layout's UI easily while editing inside IDE)	-

"post-selections" folder

This folder serves as the parent folder for all Post Selections. Every Post Selection from the Advanced Views plugin has a dedicated folder here.

Post Selections folder

Each Post Selection folder follows a specific naming structure: "post-selection-name_unique-id." For example, if you have a Post Selection with the title "Woo products" and the unique ID "651d5d75bfdf2," then the folder name will be "woo-products_651d5d75bfdf2."

Including the title in the folder name makes it easier to navigate without having to search for the specific ID. You don't need to worry about keeping the folder name up-to-date because Advanced Views automatically renames the folder when you change the Post Selection name in the user interface.

Post Selection folder files

You can find information about the files inside the Post Selection folder below:

File name	File description	Related UI field
style.css	CSS code of the current Post Selection	CSS Code (CSS & JS tab)
style.scss (optional)	Sass code* (see the related chapter of this page)	-
script.js	JS code of the current Post Selection	JS Code (CSS & JS tab)
script.ts (optional)	TypeScript code* (see the related chapter of this page)
card.php	Custom data snippet of the current Post Selection (note: in Pro only)	Custom data (Advanced tab)
query-preview.php	WP_Query preview (note: for preview purposes only)	Query Preview (Template tab)
custom [.twig] [.blade.php]	Custom template of the current Post Selection	Custom template (Template tab)
default [.twig] [.blade.php]	Default template of the current Post Selection (note: for preview purposes only)	Default template (Template tab)
data.json	settings of the current Post Selection	-
multilingual.php	multilingual stubs	-
links.md	Edit Post Selection link (allows to open the Post Selection's UI easily while editing inside IDE)	-

hidden files

".htaccess" file

Contains apache rules restricting direct access to all the files insides in browser.

".gitignore" file

When using Git: this file contains rules to exclude environment-specific files (such as links.md, which contains domain-specific information).

Template validation

When you make changes to the templates using your IDE, the plugin's template validation, which runs automatically during the 'save' process, is not triggered.

You should rely on your IDE's validation while editing a template.

Tip: You can perform a bulk template validation by going to the Layout/Post Selection list table and switching to the 'Bulk validation' tab. This process validates the Custom Template field for all existing items and displays items that have failed validation.

Sass and TypeScript usage

Every Layout and Post Selection folder includes a style.css file for CSS code and script.js for JavaScript code. You have the option to use style.scss and script.ts files and compile them into style.css and script.js respectively. For a practical example, refer to the demo repository.

While Layout and Post Selection don't have fields in the UI representing style.scss and script.ts contents, these filenames are reserved and supported behind the scenes. This means that if you disable the FS and then enable it again, these files will be restored with their content. They are also supported in import/export and the Reusable Components library.

Pro tip: In the plugin Settings, under the Defaults tab, there are 'Sass' and 'TypeScript' Template fields. If you fill them with any content (e.g., a comment line), Advanced Views will create these files automatically during Layout and Post Selection creation, saving time if you use Sass for all the Layouts and Post Selections.

Tailwind usage

Tailwind is a great utility-first CSS framework, and with the File System storage active, you can use it in Layouts and Post Selection templates. For a practical example, refer to the demo repository. If you're building from scratch, check our starter theme with Tailwind.

Tailwind is fully supported by Advanced Views. While in many cases Tailwind is used in static builds where the list of elements is known during build time, this isn't the case with Layouts and Post Selections, as their appearance is controlled by the database.

To achieve this, the demo repository has a setup where every component have its own utility classes, while Tailwind globals are stored separately. Additionally, the utility classes that appear more than once are automatically merged by Advanced Views during rendering.

Tip: If you are using Tailwind, you'll likely want to disable the BEM classes generation for the default template. You can do this in the settings of the particular Layout or Post Selection, or globally in the plugin settings. Additionally, in the Defaults tab of the plugin settings, you can define the Sass template's content, as mentioned in the repository description. This will save you from manually creating this file each time you create a Layout or Post Selection. (See the Sass/TypeScript chapter above)

Auto sync

If you're using version control in your project, such as Git, you can also consider using the File System storage option as a way to automatically deliver changes from your development environment to your live websites.

Since File System storage contains all the Layout and Post Selection settings, you can modify Layouts and Post Selections on your development website, save (push) the changes to your version control repository, and then update (pull) those changes on your live website.

This process will automatically deliver all the changes made to Layouts and Post Selections to the live website without the need for manual updates or import/export procedures.

Sync of FS-only items

If you have created Layouts or Post Selections on your Dev website and then launched them to Live using Git, these items will appear in FS-only mode. They will function like regular items, but you won't be able to edit them using the UI because the corresponding posts are missing.

If you need to make modifications to these items on your live website using the plugin's UI, you will need to 'sync' the target items. To do this, visit the Layouts/Post Selections list table, click on the "FS only" tab, and then click 'sync' in the row of the target item or perform a bulk sync.

The 'sync' process will create WordPress posts for the selected Layouts or Post Selection, enabling you to make changes using the plugin's UI. Rest assured, the Layout or Post Selection data will still be stored in the Filesystem.

Auto-removal for DB-only items

When you activate the File system storage, Advanced Views stores all Layouts and Post Selections data in the File system while utilizing the database (WordPress posts) only for UI-related things. So, if you delete a Layout or Post Selection folder in your File system, Advanced Views will automatically remove the corresponding DB-related post when you visit the Layouts or Post Selections list table.

This means that if you've launched a Layout or Post Selection to Live using Git, then performed a 'sync' to make changes to the item, and subsequently removed that item in File system in the next release, Advanced Views will automatically delete the related post, sparing you the need for manual tracking.