Support

Account

Register Login

Forum Replies Created

  • I can confirm the issue as well. With the developer console from Chrome open at the same time, an exception is thrown on return from the media browser:

    https://www.dropbox.com/s/hh2uln149v1kfpi/Screenshot%202014-09-17%2011.46.45.png?dl=0

  • Hello Kidcajes,

    If you use the get_field method, you will get the fields as an array. For some reason I can’t remember, we decided to serialize into json when saving, instead of as an array, like most other plugins does, so if you want to use get_the_author_meta, then you’ll have to json_decode($raw_data, true) to get it out as an array. But I would suggest sticking with the official get_field()-method from ACF. It does support fetching author meta, so there’s no reason to fetch it straight out of WordPress. Using the official ACF-API ensures that any additional data/parsing/restructuring, will be passed along to your functions.

    In your case, the working code would be something like:

    $var = get_field('locations', 'user_'.get_current_user_id());

    and then the $var would contain an array like you expect.

    Kind regards,<br />Morten Skyt

  • Hello Elliot,

    Ah, that’s cool – let’s see how things evolve. Maybe it makes sense to keep both, maybe it doesn’t.

    Kind regards,
    Morten @ Stupid Studio

  • Yes indeed, not a bad solution!

    In my personal case, I’ve decided to work around the ugly field keys by defining consts for all fields, grouped in classes which matches my post types.

    Basically, I have created classes with consts for each field. As I code in Netbeans, my solution has the added benefit of auto-completion for the ACF-fields. I find the added coding overhead is quite small with my solution, although there obviously is an overhead.

    class CAR {
	// Car - Base information
	const REGISTRATION_NUMBER = "field_51a66ab4a253c";
	const MAKE = "field_51a66a92a2539";
	const MODEL = "field_51a66a9aa253a";
	const MODEL_YEAR = "field_51a66a9fa253b";
	
	// Car - Geographical details
	const ADDRESS = "field_51a66dc064cbb";
	const POSTAL = "field_51a66dcd64cbd";
	const CITY = "field_51a66dc664cbc";
	const COUNTRY = "field_51a66dd664cbe";
	const GEOLOCATION = "field_51e1d1afb965c";

// ... more fields ...
}

class USER {
	// User
	const AVATAR_URL = "field_51e306ce37798";
	const FACEBOOK_USER_ID = "field_51e3070737799";
	const NEWSLETTER = "field_51e47ad26a7a6";
}

    So when I want to update or get a field, I now do:

    update_field(CAR::REGISTRATION_NUMBER, $registration_number, $postID);

    It works quite well for me. Nonetheless, I stand by the feature request. I would have preferred simply having to write the following and not worry about extra classes and consts:

    update_field('registration_number', $registration_number, $postID);

  • I’m quite sure that there’s a good reason for using the random string. Nonetheless, in a perfect world, such necessary work-arounds would be shielded fully away. By browsing old threads, it does seem that I’m not the only one who has found this extra hidden field a bit annoying to work with.

    I hope one day, the API will work consistently, even if you choose to use the field name and create posts from code and not through WP Admin 🙂

Viewing 5 posts - 1 through 5 (of 5 total)