Search Results for 'slow saving'

• In reply to get_field() doesn't return a value when fields are created with update_field()

• February 3, 2016 at 5:54 am

I’m not the developer of this plugin, I just help out around here on the forum, so take what follows as just the views of another user that happens to also be a developer that build similar thing and spends a lot of time weighing the pros and cons of different approaches to a problem.

Could it be possible? Yes. You can get the field groups, loop through them and find the field and then extract the key.

The problem is, you can have multiple fields with the same name, but they will have unique keys. If there is more than one field matching the name you’re looking for, which one do you use?

After the post is inserted, you can possibly get only the field groups that would be on that post. This requires invoking all of the location rule logic which will slow the process down. Then you still need to loop through all the field groups and fields to find the one you’re looking for. There will still be the problem of what to do if you find more than one field with the same name.

The problem with the ability to have multiple fields with the same name is more than likely the main reason why ACF does not do this. The second someone had multiple fields with the same name and the values get screwed up because ACF used the wrong field key someone would be here reporting a bug that would really have no solution other than Elliot telling you that you can never have more than one field with the same field name. I don’t think that would be very popular.

Searching thought fields is the second reason, it’s just not practical. ACF stores fields by the field key. Using the field key you can go straight to the field in question instead of searching for it. Once a post is updated this can be done by doing a database query to get the field key. It is still faster to use the field key directly because the removes the need to do te second query. There are already complaints about the speed that ACF works, searching for and matching up field names with keys would create additional losses in performance.

I don’t really see this as any kind of a problem to be honest. Instead of copying the field name I copy the field key. Since I usually have the field group displayed on one screen while I’m coding on another I just copy what I need. And even if I was using the field name I still copy and paste. Why? because it reduces the coding errors due to my dyslexic typing.

What do I do when I need to use field keys for something? Here’s an example of something I recently used in a project:

$fields = array(
  'equipment_condition' => 'field_568ad9d81e788',
  'equipment_year' => 'field_568ada4e1e789',
  'equipment_manufacturer' => 'field_568ad61835f56',
  'equipment_model' => 'field_568adac11e78a',
  'equipment_category' => 'field_568ad6d535f57',
  'equipment_serial_number' => 'field_568adba61e78d',
  'equipment_desc' => 'field_568bf44e39b14',
  'equipment_short_desc' => 'field_568bf47639b15',
  'equipment_spec_relationship' => 'field_568bff47e0c3b'
);

Using the above array I can now refer to the field I want using the name
update_field($fields['equipment_manufacturer'], $value. $post_id);

As far as ACF saving a post, have you ever looked at the fields that ACF generates on a post edit screen? If you do you’ll notice that the name used for the input field is the field key and not the field name. ACF uses the same method for updating fields, using the field keys, because it is the only value that uniquely identifies the field.

I look at it this way, the only real purpose that the field name has is to make it easier to get the values on the front end because they are easier to remember and type than the field keys. The only reason that ACF needs dual entries in the database is to provide developers with this easier method to display values and it also makes it so that you can use get_post_meta() using the same name if you chose to do so. It exists for the 90% of the people using ACF that will never modify field using code. For the 10% of us that want to do more complicated things we’re expected to do a bit more work.

• In reply to Flexible Content does not delete post meta properly

• October 23, 2015 at 10:16 pm

Yes. ACF would need to either keep track of what was deleted and submit some kind of delete flag or it would need to query the database before saving and compare the old data to the new data before saving. The final choice would be to delete all of the old content and then insert the new content.

I don’t know how practical the first choice in and the last two would significantly slow down the admin because ACF would have to do twice as much work. I’m also not really sure how this would effect revisions.

If really want that data to be removed then the best solution there is would be to create an acf/save_post filter that runs before ACF does the save. Then you could figure out how to compare the data and do the deleting.

I’ve never really had a problem with some old data lingering in the db.

• In reply to JS performance issues

• July 17, 2015 at 10:05 am

Hi. I use ACF a lot and love all the features you’ve made available, particularly the convenience of the repeater fields and conditional rules.
However, in trying to use this for websites that require a lot of conditional logic (as a layout builder of a sort) I’m having the same issue with the admin area mentioned above – specifically with extremely slow opening the page, creating a new field and saving the page.
On the front end the load time is fine so this is really just an issue for the admins and managers.
Even if I make no changes to existing field values and attempt to save the page there’s a major slowdown. Shouldn’t it be checking for changes to field values before saving? Then if no changes have been made, shouldn’t it skip the fields and not do anything at all?
I don’t want to switch to anything else as I haven’t found anything else as feature rich or as simple to manage on the admin area (and with all these nifty filters and actions) but looking forward I can’t see being able to continue using this as our standard plugin if it isn’t adjusted to have a lighter touch and to not do things when it doesn’t have to. I’d be forced to go back to hand-coding stuff or using a less feature-rich plugin, which would suck 🙁 I’d much rather use ACF.
Could we please know if this is being worked on? The conditional rules are an essential function with as many fields as I’m working with so I can’t simply not use them…and this behavior makes it nearly unusable in some cases.
But I don’t want to end this without saying another ‘thank you’ to you for building this in the first place. It speeds up me and my teams’ work considerably 🙂

• In reply to ACF not saving fields – tried everything

• April 10, 2015 at 10:55 pm

Same problem here… and getting desperate…

Checked max_input_vars, nesting_levels, input_time… Also changed option_name to 255 chars… Nothing.

No errors neither in php logs, apache or mysql. No slow queries… I’ve debugged with save_post and acf/save_post and the array is complete in WP debug.log (it includes the not saved fields)… But they do not save to the DB…

This behavior started after adding a repeater field in a field group. I had a lot of custom posts with custom fields working fine. Then realized I needed one more repeater field and added to the field group… This made the fields stop saving…

Some magic would be greatly appreciated 🙂

Latest version of WordPress and ACFPro at this time.