File system storage

About the feature

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

Please note that this is a storage-only option, and for creating and configuring Views and Cards, 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 Views or Cards.

How it works

Views and Cards 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, View and Card 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 Views and Cards 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, the Advanced Views Framework creates an "advanced-views" folder inside your theme directory. This folder contains the following items:

"views" folder

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

View folder

Each View folder follows a specific naming structure: "view-name_unique-id." For example, if you have a View 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 View name in the user interface.

View folder files

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

File nameFile descriptionRelated UI field

style.css

CSS code of the current View

CSS Code (CSS & JS tab)

script.js

JS code of the current View

JS Code (CSS & JS tab)

view.php

Custom Data snippet of the current View (note: available only in the Pro version)

Custom Data (Template tab)

custom.twig

Custom template of the current View

Custom template (Template tab)

default.twig

Default template of the current View (note: for preview purposes only)

Default template (Template tab)

data.json

settings of the current View

-

multilingual.php

-

links.md

Edit View link (allows to open View's UI easily while editing inside IDE)

-

"cards" folder

This folder serves as the parent folder for all Cards. Every Card from the Advanced Views plugin has a dedicated folder here.

Card folder

Each Card folder follows a specific naming structure: "card-name_unique-id." For example, if you have a Card 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 Card name in the user interface.

Card folder files

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

File nameFile descriptionRelated UI field

style.css

CSS code of the current Card

CSS Code (CSS & JS tab)

script.js

JS code of the current Cardiew

JS Code (CSS & JS tab)

card.php

Custom data snippet of the current Card (note: available only in the Pro version)

Custom data (Advanced tab)

query-preview.php

WP_Query preview (note: for preview purposes only)

Query Preview (Template tab)

custom.twig

Custom template of the current Card

Custom template (Template tab)

default.twig

Default template of the current Card (note: for preview purposes only)

Default template (Template tab)

data.json

settings of the current Card

-

multilingual.php

-

links.md

Edit Card link (allows to open View's UI easily while editing inside IDE)

-

hidden files

".htaccess" file

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

".gitignore" file

For those who use 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 View/Card 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 View and Card 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.

Tailwind usage

Tailwind is a great utility-first CSS framework, and with the File System storage active, you can use it in View and Card templates. For a practical example, refer to the demo repository.

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 View or Card, or globally in the plugin settings.

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 Views and Cards, 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.

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 View and Card settings, you can modify Views and Cards 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 Views and Cards to the live website without the need for manual updates or import/export procedures.

Sync of FS-only items

If you have created Views or Cards 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 View/Card 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 Views or Cards, enabling you to make changes using the plugin's UI. Rest assured, the View or Card data will still be stored in the FS.

Auto-removal for DB-only items

When you activate the FS mode, Advanced Views stores all Views and Cards data in FS while utilizing the database (WordPress posts) for UI-related things only. So, if you delete a View or Card folder in FS, Advanced Views will automatically remove the corresponding DB-related post when you visit the View or Card list table.

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

Last updated