Skip to content

From Magic Fields 1.x to ACF, Part 6

Other posts in this series: Part 1; Part 2; Part 3; Part 4; Part 5; Part 6 (this post); Part 7; Part 8; Part 9

Pods Framework

The Pods Framework looked a little daunting when I first investigated it a couple of years ago. Now, with a lot more custom-field and content-type knowledge under my belt, it’s worth another look. There’s an extension available, Panda Pods Repeater Field, that may do what I want. So I’m activating Pods, and installing and activating Panda Pods Repeater Field.

I gotta say, Pods is as slow as s____. Every click takes many long seconds for the screen to come up. Not like anything else I’ve worked with today.

But looking through the tutorial for the Repeater Field add on, it’s got a few problems. One, it’s overkill. Two, it’s complex. And three, it’s dependent on creating new tables. Not that I have a 100% firm objection to new tables, but one issue with Magic Fields that makes it difficult to move away from is all the custom tables. I really would rather have something that just sticks to the PostMeta table that’s built in.

But maybe the answer is easier?

I’m stuck on repeater fields. But for this particular implementation, there are a finite number of repeats I’m going to need. For example, I can track down how many churches have more than one architect by querying the database. The answer is 13, and none of them have more than three.

You can get this info by running a query similar to this:

SELECT post_id, COUNT(*) row_count FROM `prefix_1772_postmeta` WHERE meta_key='church_building_architect' GROUP BY post_id ORDER BY row_count ASC;

This also gives me a clue that the two post entries that have three listings (post_id 463 and 536) are ones to keep an eye on.

The hack I can derive from this is using the “Group” content type.

ACF Group Field Type
The labels and names stay the same.

From there I can go on to add a sub-field. Subfields are groups of related fields. For example, if I wanted to put in details I could have the architect’s name, firm, active dates, other notable buildings. But I just want the name. And then I’m going to take that field and duplicate it:

Duplicate
Hover over the label to find and click on “Duplicate”

I’ll name the copy “Architect Name 2” (field name “architect_name_2”) and then apply conditional logic to it:

Conditional Logic
Only show Architect Name 2 if Architect Name has a value

And again with the third possible entry. This logic makes the additional entry fields appear once the ones above are populated, creating the same functionality as a repeater field except for the fact that the number of possible entries is limited.

More conditional logic image
And the third architect field only appears if the first two are populated.

This works for me because the project is essentially finished. The buildings are catalogued, they’re already built so new architects are less likely to be added (though in the case of a major renovation, yes). But the boundaries are seemingly finite (more on that in a moment), unlike a true repeater field where you might need to add hundreds of items.

As I run through a quick survey of the repeatable fields, I find most of them are manageable. No church has more than five notable works of art, for example. One church as 10 bells, each is named after a different saint, with a different weight, and a foundry. That same church lists 9 different renovations.

Others show repeated fields that don’t make sense. “Current status” should only have one entry, but my query shows three. A “SELECT *” shows that two of them are blank — it should never have been set up as a repeater anyway.

But

There is a church that features 85 different interior photographs. That’s a lot of duplicating.

In looking at some of these oddball entries that have unusual numbers of fields I see that the meta_value of a lot of them is empty. It would be nice to blow some of these away in the future, because they’re not really helping. But their time will come.

First Test

I created an imaginary church building, and populated the three architect entries. The data looked like this:

35847
2013
church_building_architect_architect_name
Cesar Pelli

35849
2013
church_building_architect_architect_name_2
Frank Lloyd Wright

35851
2013
church_building_architect_architect_name_3
Eero Saarinen

(leaving out some of the meta fields.)

As I build out my custom template, I’ll certainly be able to do an if … then test on the successive rows, and only show them if they’re populated.

Similarly, I should be able to write a script to take the architect name rows and re-name them. Now one thing I didn’t worry about in the previous project, that I ought to take a look at now, is the set of meta_key/meta_value pairs that look like this:

_church_building_architect_architect_name
field_5efcc90e3d7d8

These “field_xyz” entries are the same no matter which post they’re attached to. And in fact, they’re created automatically whenever a post is published or updated, even if no changes have been made. So for example,

SELECT * FROM 'prefix_1772_postmeta' WHERE post_id=1819 AND meta_key LIKE '_%' AND meta_value LIKE 'field%';

Returns an empty set. Then I’ll open the post for editing…still an empty set. Then I’ll simply click the “Update” button…and the query returns 23 new rows.

Let’s try something else. Post 1814 returns zero rows; go into the Quick Edit pop-open and click “Update” again…empty set. So that’s not happening.

Next I tried using CLI, hoping there would be a command that would trigger the update the same way that click the blue button in the browser did.

bash-4.2$ wp post update 1814 --url=http://blogs.shu.edu/newarkchurchescopy --post_status=published
Success: Updated post 1814.
bash-4.2$ wp post update 1814 --url=http://blogs.shu.edu/newarkchurchescopy --post_status=draft
Success: Updated post 1814.
bash-4.2$ wp post update 1814 --url=http://blogs.shu.edu/newarkchurchescopy --post_status=published
Success: Updated post 1814.
bash-4.2$ wp post update 1814 --url=http://blogs.shu.edu/newarkchurchescopy --revised_content=true
Success: Updated post 1814.

But no dice.

Where do these come from anyway?

The answer is, when you create any custom field it goes into the wp_posts table as a post. The post_name will be (for example) field_5efccab3d7d9. And it’s important because the post_content field holds the rules for the field. They’re all kept in a serialized array like so:

a:10:
  {s:4:"type";s:4:"text";s:12:"instructions";s:0:"";s:8:"required";i:0;s:17:"conditional_logic";a:1:
    {i:0;a:2:
      {i:0;a:2:
        {s:5:"field";s:19:"field_5efcc90e3d7d8";s:8:"operator";s:7:"!=empty";}
      i:1;a:2: 
        {s:5:"field";s:19:"field_5efccba23d7d9";s:8:"operator";s:7:"!=empty";}}}
  s:7:"wrapper";a:3: 
     {s:5:"width";s:0:"";s:5:"class";s:0:"";s:2:"id";s:0:"";}
  s:13:"default_value";s:0:"";
  s:11:"placeholder";
  s:0:"";
  s:7:"prepend";
  s:0:"";
  s:6:"append";
  s:0:"";
  s:9:"maxlength";
  s:0:"";}

That one is for the third of the Architect fields. The conditional logic is that this field appears if the first and second Architect fields are populated — named by their post_name values of “field_5efcc…”.

Without being linked to these rules you might be sunk if you try to update or add to your fields.

It looks like the best I can hope for is to populate them all by running a series of CLI commands, like this:

wp post meta update 1783 --url=http://blogs.shu.edu/newarkchurchescopy _name_of_parish field_5ee1430dc3928

Running this query:

SELECT * from wp_1772_postmeta WHERE meta_key LIKE '_%' AND meta_value LIKE 'field%';

returns 173 rows, which is only going to grow as I expand out my multiple fields. By the way, there are 183 posts that are going to need updating, even after I change the namings in the database. I’m not sure that going into 183 separate post edit screens and saving them is going to be the way I want to spend the day. But however I approach the next step, I have to create my multiple fields.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Share This