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:
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 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:
style.css
CSS code of the current View
CSS Code (CSS & JS tab)
style.scss (optional)
Sass code* (see the related chapter of this page)
-
script.js
JS code of the current View
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 View (note: available only in the Pro version)
Custom Data (Template tab)
custom [.twig] [.blade.php]
Custom template of the current View
Custom template (Template tab)
default [.twig] [.blade.php]
Default template of the current View (note: for preview purposes only)
Default template (Template tab)
data.json
settings of the current View
-
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:
style.css
CSS code of the current Card
CSS Code (CSS & JS tab)
style.scss (optional)
Sass code* (see the related chapter of this page)
-
script.js
JS code of the current Cardiew
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 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] [.blade.php]
Custom template of the current Card
Custom template (Template tab)
default [.twig] [.blade.php]
Default template of the current Card (note: for preview purposes only)
Default template (Template tab)
data.json
settings of the current Card
-
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.
While View and Card 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), AVF will create these files automatically during View and Card creation, saving time if you use Sass for all the Views and Cards.
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're building from scratch, check our starter theme with Tailwind.
Tailwind is fully supported by AVF. 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 AVF 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 View or Card, 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 View or Card. (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 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