This isn’t particularly a sage specific question but a general theme development workflow question.
When working with custom designs there are certain pages like Homepage, about-us and contact-us etc. pages which can’t be created in a template setup as they are very unqiue. These pages have very unique and specific content structure requirments. How do you save these contents so that client can edit as and when they want.
My Current Solution
I create a custom post type website-customization
Restrict its access to guest users.
Add custom fields for different pages. for example : I would make a post about-us and conditionally add custom fields there which can be edited by the client. I use Toolset plugin to create them. I have seen a lot developers here use acf, and am open to switch given that it gives me better solution.
When pulling data for about-us page I find a post by about-us slug and then find the content.
Issues with this approach.
-> It doesn’t feel natural. If someone changes the slug to something else the data won’t be detected.
-> When going live I have to do re-work of database fields creation, which is a waste of my time. I hope acf can help me with this.
How do you manage these situtaion ? Are you using blocks ?
I found the Gutenberg editor to be great. I can use core group and cover blocks with different block styles.
For stricter layouts I also used the Mesh plugin: https://wordpress.org/plugins/mesh/
ACF Pro + Gutenberg is awesome (See ACF Blocks, essentially an ACF Pro feature that wraps Gutenberg block registration in an ACF supplied API, and leverages the standard ACF field creation interface to customize the content fields for the new block). It’s very flexible/powerful.
And for added slickness, use https://github.com/MWDelaney/sage-acf-wp-blocks to simplify ACF Block registration by providing the ability to define a new ACF/Gutenberg block directly from the head matter of a Sage/Blade template.
ACF is also able to save out your custom field configurations on the fly to JSON in your theme folder, so with this approach, your template, block definition, and custom field configurations are all captured in source control.
Hey @timichango, this looks very good. I can see myself using ACF for my upcoming projects.
In a gist, I will basically be able to create gutenberg blocks ( without coding any react code ) and my client can basically use this block however they want. This would make things really easier for us (we provide documentation on how to edit content) and for them to make changes, order sections up or down with dragging and dropping.
I have never actaully used ACF. I have questions regarding the workflow. Can you help me with the following;
I can see the registration of blocks using PHP, but when I look at step 2 (Create a field) it look like I will have to create field groups by visiting admin dashboard. Can this be eliminated ?
Q => Is there any PHP API which would help me to register fields and I don’t have to transfer my database to production site when pushing changes ?
Sage ACF Gutenberg Blocks look very useful, with adequate filters. I can see EnqueueStyle and EnqueueScript to add CSS and JS to the block.
Q => Can we use .scss files ? How do you make your CSS and JS scoped ?
I can understand that when working with clients I would be creating maybe 10-15 blocks for a small business website. Given that I would be registering fields(if possible) using PHP.
Q => How do you manage your PHP code ? Do you prefer to keep your PHP for fields?
I do find ACF blocks exciting and very useful, but what’s your take on creating blocks usign the native gutenberg way Vs. ACF way ?
Yes, you would declare the block in PHP (or in your blade template for the block if you’re using the sage-acf-wp-blocks library I mentioned earlier), then create your new ACF field group using the ACF Pro admin panel in the site back-end. There might be a way to set up your fieldgroups/fields from PHP (review ACF documentation — I think there’s an API), but since, as I mentioned earlier, your fieldgroup configurations can automatically be saved out to JSON inside your theme folder when they’re created/updated, and that JSON can be pushed to your live server with your code deployment, you don’t need to also deploy your database at all. See https://www.advancedcustomfields.com/resources/local-json/
I haven’t used the EnqueueStyle feature, so I can’t be of assistance there. I’d ask the developer of that library. I have used EnqueueScript on a recent project, and it worked well. Not sure about scoping — you’d need to play around with it.
Again, I’m using ACF Pro’s Local JSON feature, so can’t advise on anything related to field config via PHP, as I have no experience with that.
As far as native Gutenberg vs ACF… frankly, I’ve been using ACF Pro for years prior to Gutenberg coming along, and after hearing about how much rigmarole is involved with setting up custom blocks the native way, I never even bothered trying to go that way, and have only used ACF Blocks for sites that need custom blocks.