Why I used ACF Pro instead of Pods this time
I like Pods a lot as the ‘all-in-one’ solution for both CPT and custom fields creation, together with the many-to-many relationship possibilities. Why did I decide to use ACF Pro instead for my latest webproject?
Well, first things first. The webproject I had to develop were based on three independent custom post types with their own fields: products, customers and producers. There were no demands of combining views of data together on both archive and/or single post pages.
Second, I gues I am experienced enough now to copy/paste some PHP in functions.php of the websites child theme to create the custom post types and the various taxonomies needed.
Third, the back-end user interface for the customer should be as simple as possible, so I wanted to create some simple ‘custom options pages’, needed to setup up some global value for header, footer and some other global needed on various places on the website.
That brought me to the use of ACF Pro. Not because it could not be done ‘simple’ in Pods, but just because I only needed to create the fields I needed for the three custom post types I created.
No need to explain the Beaver Builder and Beaver Themer are the core components for building this site
Admin Columns Pro
To make things accessible for the end-user Admin Columns Pro is for me the ‘standard’ in every project to show the enduser all the data they need to make any decission in the back-end for the data needed in the front-end for their visitors. It runs very smoothly on the custom post types listed in the back-end. And also the ACF Pro add-on makes it easy to add any custom field in the bak-end list of custom posts.
Excel sheet
The existing website was built with Elementor. For customers and producers no custom post types were created. They were ‘just displayed’ as a custom made series of rows and columns with the images (logos) of the companies involved. There was nothing behind it, no text, no links, just two series of images. So for the new website they had to be recreated as custom posts and some extra fields and taxonomies. That makes the data easier accessible for future maintenance.
The product were stored in an inbuild custom post type via a plug-in called Ultimate Product Catalog. The pro version made it possible to use custom fields as well, but they did not use that feature. The content, weight and packaging of each product were ‘just written’ as palin text in the description text field. Too bad, they missed that feature. Ofcourse Ultimate Product Catalog was not used in the new version of the website…….
The plug-in offered the possibility to export the content, so I took that road instead of using the standard WorPress Export feature. That worked good enough, a CSV file was created with all data of a little more than 160 products.
Cleaning up
After exporting all media files I ended up with a lot of clutter. Resolutions of images going far beyond 2000 pixels, filenames with no logical names with sometimes more than 40 character,s and stuff like IMG12345.jpg or product98765-scaled.png. For a SEO based approach, not the best way to start with. So I had to make the decission (together with the customer) to clean this mess up before importing all media files in the new Media Library. I did use a little routine in functions.php that filled the ALT field for each image, but for the rest I had to manually handle about 160 mediafiles, which took me a couple of hours (extra).
WP All Import/Export Pro and SEOPress Pro
The very best way to import structured data from various fields and taxonomies is WP All Import wit the Pro add-on for ACF. For all SEO purposes I wanted the SEO fields to be filled during the import, so the SEO title became the custom post title for each product and the SEO description became the Excerpt for each post.
Before importing all records I uploaded the 160 mediafiles to the new Media Library, and with that the ALT tags was generated for SEO purposes as well.
I did run some tests with 4 records and the import worked fine, featured image was set nicely and the galery filed in ACF was filled with (in this case) just one image per product.
For getting the SEO data in (normal core WordPress custom fields) I had to ‘migrate‘ a test export for just one time to tell SEOPress to supply their fields in the WP All Import list for setting the values needed.
After the whole setup was ‘double checked’ I decided to import the 160 products in just a couple of badgets to provent any risc of time-out errors. WP All Import has some strict requirements for the server it is running on.
Two languages
Like the previous project, this website also needed support for another language. I decided not to use WPML, because of all of the add-ons and the enomous setup complexity. The Beaver Builder team published a nice article on TranlatePress. Their suopport for Beaver Builder was explained in a article on their site, so I decided to give that one a try. For SEO purposes I bought the Personal Edition (€79 per year).
The whole translation process went smoothly, also for taxonomies. Using Deepl.com generated the well translated parts for eacht page, and custom posts. The 160 products are to be translated by the customer later, after the site goes online. Just one short paragraph per product.
Summary
Choosing ACF Pro above Pods was just one ‘little’ decission in the whole process of rebuilding an old cluttered site to a more modern approach which would be friendly enought to be used by non-WordPress used endusers. The site just has a homepage and a contactpage, the rest of the three menu items are ‘just’ archive views for products, clients and producers. They were created in Themer, just like Header and Footer. FacetWP is there for filtering the products together with the search plugin Relevanssi.