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.
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!
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.
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.
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.
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 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?
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?
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.
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.
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
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.