Support for advanced custom fields 5 fields in widgets

Beaver Builder
#1

Hi

Thanks for a great plugin, we will use the page builder now in our next customer project which is exciting.

Advanced custom fields is a pretty well know plugin/framework and in acf5 there is support for using fields in widgets.

This is kind of cool since it makes it quite easy to create custom widgets very easy, which then could be used together your page builder to build even more customized websites.

However when I try this it seems like acf5 fields are not showing up when adding this widget with the page builder.

You can find acf5 through https://github.com/AdvancedCustomFields/acf5-beta

To show you I have put together this example.

I have created a field group with 2 fields that I have decided should show on the widget Meta. https://drive.google.com/file/d/0B18DXlchF8TxRTVJTTJXVnYtdFk/edit?usp=sharing

And it shows correct when I edit this widget in the regular WordPress widget administration. https://drive.google.com/file/d/0B18DXlchF8TxVUZzQXlYTzhBYk0/edit?usp=sharing

But when I add this widget in the page builder I don’t get the fields. https://drive.google.com/file/d/0B18DXlchF8TxLXMycDVaYno4LUE/edit?usp=sharing

Really appreciate your help/thoughts on this, thanks.

#2

Hi there, thanks for your interest in our Page Builder plugin and apologies for the inconvenience! This is an issue we will need to look into further, test, etc. We have issued a support ticket for this issue and will let you know when we have more info/a fix. Stay tuned and thanks again!

Best,
Billy

#3

Hi wpkonsulterna,

I looked into a solution for this and unfortunately, it’s not something we’ll be able to support at this time (you’ll notice other builders like Site Origin don’t either).

I’ll keep an eye on this request and if it becomes popular, I’ll look into submitting a patch to ACF that would expose the necessary functionality we need on the frontend for it to work.

Thanks,
Justin

#4

Have you had a look at our custom module documentation? Instead of using ACF to create widgets, you could create custom modules for the builder with similar functionality. Let me know if you have any questions about that.

Justin

#5

Hi Justin

Thanks for your reply and looking in to the issue. I actually posted the issue myself to both Site Origins page builder support (http://siteorigin.com/thread/support-for-advanced-custom-fields-5-fields-in-widgets/) and to acf5 github (https://github.com/AdvancedCustomFields/acf5-beta/issues/308). You’ll find both Greg’s and Elliot’s responses through the links.

The custom module is absolutelly an option for us finding a good way to build custom widgets rapidly and which are easy to use would be better for us for 3 reasons:

  • We can use widgets not only in content but also eg. in the footer, header or any other sidebar on the website
  • If we at some point would like to move to another page builder or when core get support for this type of functionality it is easier for us to change if the content blocks are not tied to a specific page builder
  • Frameworks like advanced custom fields have support for many different and easy to use field types. Also it is well known by many developers, well documented and possible to extend with custom field types.

Using the custom module possibility is still an option, I guess we rather need to look in to what options we have and make a decision. However using custom widgets and finding a fast/reliable way of developing them still seems like the best approach for us.

Really appreciate your thoughts and support on this.

Thanks for a great product and great support.

Johan

#6

Hi Johan,

You’re welcome, thanks for the detailed follow up!

I believe Site Origin will have an easier time than us implementing this as their builder works on the backend. Many plugins, such as ACF5, check is_admin() before enqueuing their styles and scripts. This means that they aren’t loaded on the front-end when the builder is active. So, even if we got the ACF5 widget fields working, any of them that depended on ACF5’s styles or scripts would be broken. I suspect other front-end builders have this issue as well.

I agree with the advantages of creating custom widgets using ACF5 and would like to make that work. Before we can do that we need to figure out the is_admin issue. I’ve been thinking about that one for a while, so I can’t promise that we’ll have a solution soon. But it is on our radar.

Thanks,
Justin

#7

Hi Justin

Thanks for the follow up. Just a question, do you gave any other experience or suggestions on “field frameworks” other than acf5 that could be good to use when trying to rapidly create custom widgets?

Thanks

Johan

#8

Eg. Piklist (http://piklist.com/) seems to be another good looking framework, but the example widget in the plugin also don’t work. Maybe the same issue as with acf5?

#9

Hi Johan,

I’m not sure but will look into it for you this week. I’ll let you know if it’s something that we can provide support for. I haven’t given up on ACF5 support yet. I’ve explored a number of solutions without success and will continue to put some thought into it.

Justin

#10

Hi

Any update on this, we need to start development on custom widgets in the coming days and then also make a decision on what framework to go for.

We are deciding between the following frameworks:

Thanks for your help!

#11

Hi Johan,

Apologies for the delay. Unfortunately, we’re not going to be able to support ACF5 for widgets right now. That’s something we may revisit in the future when it’s out of beta, but for now, we’ve spent quite a bit of time on it with no results.

Pods and Redux
What specifically about Pods and Redux do you need support for?

Piklist
I tested this and unfortunately, like ACF5, we won’t be able to support their custom widgets at this time.

Sorry I don’t have a better answer for you! I definitely understand that being able to rapidly create widgets is important, and really do want these plugins to work with the builder.

The issue of custom 3rd party fields in widgets on the front-end is a tricky one that is going to take some time for us to figure out. We’re working on a few popular requests right now, so I can’t promise that we’ll revisit this soon, but it’s still on my list to revisit at some point.

Thanks,
Justin

#12

Hi Justin

Pods and Redux would be used the same way as piklist and acf to easily create widgets.

So the issue is primarily that the page builder operates in the front end? Acf have support for displaying forms on the front-end, don’t know if this documentation could be applicable to the situation? http://www.advancedcustomfields.com/resources/how-to/create-a-front-end-form/

I have now also posted the issue to Piklists support forum, http://piklist.com/support/topic/use-a-piklist-widget-with-fastline-page-builder/, so you know.

Thanks

Johan

#13

Hi Johan,

Thanks for the follow up. The ACF link looks very promising! I’ll have a look into that early next week and let you know what I find.

So the issue is primarily that the page builder operates in the front end?

Yes. The main reason is that many plugins only run their logic in the admin, not the front-end, so it is not accessible to the builder.

Justin

#14

Hi Justin

We’ve tried to look into the Piklist issue ourselves a bit more and it seems like the problem is due to the fact that Piklist creates classes for the widget based on its name, and that FastLine struggles to create an instance of the class.

We assume this from the error we get when I try to add a widget to a page:
Fatal error: Class ‘piklist_universal_widget_wpk_pricing_table’ not found in /nas/wp/www/cluster-2612/insted/wp-content/plugins/fl-builder/modules/widget/includes/settings-general.php on line 12

Any suggestion on how we could resolve this?

Thanks

#15

Hi Johan,

It looks like the widget class they are creating is either not available on the front-end or that it’s not actually instantiated from the “piklist_universal_widget_wpk_pricing_table” widget slug as other widgets are.

You might ask them about where this classes is being created and made available. We can go from there.

Justin

#16