What’s the best place to keep my Advanced Custom Fields variables?
I know it’s bad practice to have anything like this in a blade template… so where could I store them and call them into the template?
So say i make a controller for my homepage template:
public function images()
{
return get_field('images');
}
and Just display it in my template eg:
{{$image['alt']}}
Rather than creating a bunch of functions to return one field, I should be able to create one function in the controller that uses all the fields i have in my first comment like:
public function homepageFields()
{
return array (
$subheading => get_field('subheading'),
$video = get_field('video_link')
)
}
Would that be the right syntax / way of going about it? and how would I display, the $video in the array, in the template? if it’s in the App namespace, ie:
In your second example, you’d be able to access video in your Blade with the following:
{{$homepage_fields['video']}}
Methods in the App namespace are available to every Blade, unless they’re overwritten by another controller–i.e. if you had a controllers/FrontPage.php controller file that also defined homepageFields(), the $homepage_fields variable in views/front-page.blade.php would contain the value returned by the controllers/FrontPage.php version of homepageFields() instead of the one defined in controllers/App.php.
Personally, I don’t like to group unrelated data together in the variables I pass from my controllers to my Blades, because then my templates become more opinionated about how they handle data. That being the case, I’d separate out subheading and video instead of returning them as an array, but that’s a personal preference.
I split my templates down into components (location is a component used on the home page) and then use a method per component. I feel like this keeps everything nice and logical.
No problem. All pretty new to me too but once you’re past the initial learning curve, it all clicks very nicely. Having super clean views/templates is particularly satisfying. Maintainability is also greatly improved thanks to the separation of logic and templating. I find that once all the logic is taken care of, moving stuff around/amending your templates is really easy.
It is awesome, that’s what I love about React.js, it’s funny, where I work, we run an MVC environment but it’s such a mess, with php logic and everything in-between mashed into the templates haha so it’s good to understand the proper way of doing it
This is what I like the most. I can shove all the ugly logic I need into a controller and keep my template clean with {{ $resultOfUglyLogicOhGodDontLookAtIt }}
Using object syntax like this is very clever and I like it a lot! I realize it’s mostly aesthetic preference on my part, but for some reason $container->field always looks so much nicer to me than $container['field'].
I’m just getting started here, but this has really given me new hope for Wordpress. I always got frustrated that my template files would get so messy when you started adding logic for ACF fields and so on.
I have created this Related Posts snippet. It utilizes an ACF Bidirectional Post Relationship plugin. The code is as follows:
Ideally I’d like to remove as much as the logic from the template file. I’ve seen the examples above and I think I get it, but the global $post, The loop and wp_reset_postdata confuses me.
Totally untested and assumes that your returning your related post as the post ID not an object (by looking at what you posted up). It involves two loops (one in the controller and one in the view) but it keeps the view very tidy in my opinion.
It would be fairly easy to build in an acf helper class into Controller that speeds up the process of looping through fields and then outputting to an object notation. All you would need to use in the view then would be @foreach (for repeater fields). Basic fields could be flattened using the key as the variable name.
If you’re using acf in a standard way, it could all be automated to be honest. I’m going to look into building a prototype module over the next few days should time allow.
Been working on something like this. All values returned to the view are returned in object notation should that be required.
In a Controller Class;
<?php
namespace App\Controllers;
use Sober\Controller\Controller;
use Sober\Controller\Module\Acf;
class Single extends Controller
{
// all returned values from Acf, even if multidimensional arrays are in object notation
public function acf()
{
return Acf::get();
// gets all fields
// use $acf->repeater in view
// use $acf->text_field in view
}
public function text()
{
return Acf::get('text_field');
// gets 1 field and returns flattened
// use $text in view
}
public function combo()
{
return Acf::get(['repeater_field', 'text_field']);
// gets 2 fields, and returns in object notation using advanced custom fields key values
// use $combo->text_field in view
// use $combo->repeater_field in view
}
}