- This topic has 7 replies, 3 voices, and was last updated 6 years ago by
.
-
Posts
-
-
I wonder if it would be possible to clarify why Piklist widgets cannot be used with SiteBuilder’s Page Builder rather than dismissing it as ‘they’re not following the rules’ (this topic was closed – apologies for re/opening an issue that may have been considered addressed).
From my limited experience with WordPress, it seems that Page Builder this is an essential tool that avoids the mess of hard-coding solutions that can more easily be addressed this way.
Perhaps a wrapper of some kind could be developed that is compliant with Page Builder and bridges to Piklist widgets? I see this as a multiplicative solution where payoff is considerable and the effort (at least in principle) should be manageable, unless there is something fundamentally diametrically opposed in the way these approaches work with each other.
Can someone jump in an offer some insights about the existing limitations and how they could be worked around if someone were willing to put that effort in?
-
@claude– While compatibility with other plugins, especially one as popular as PageBuilder is important to us, we are a small team and need to manage our time. Right now we are spending our time writing unit tests for Piklist and getting the next version ready.
If you would like to take a look and submit a patch please email us at [email protected]
-
Hey Steve, I wasn’t implying that you should prioritize this but rather that you might be able to take a moment to explain the gap, as your look at the problem (from he previous thread) may have revealed. Someone could then use that guidance to take a closer look and maybe, as you suggest, submit a patch if the gap is not too wide.
I’m pretty tech savvy but completely new to PHP and WordPress. Most of my expertise centers on the (Enterprise) Java stack, and to slightly reduced degree the Microsoft stack. Web front-end technologies (HTTP/HTML/CSS/JS) are even more familiar since they tend cross those stacks so that part is quite familiar. I’m on my 5th book about WordPress but I only started gearing up for this project 3 weeks ago.
BTW: I’m impressed with the agility that WordPress brings to the table, especially with a tool like Piklist (the more I dig in the more impressed I am with you and your team’s work). I’m less impressed with PHP as a language/markup engine but I can see how it became the basis of so many web projects.
-
@claude– I wasn’t implying that you were implying… 😉
We haven’t even looked at this issue, and probably won’t until v1.0 is released.
Glad you’re liking WordPress and Piklist.
Let us know if you have any other questions.
-
The best explanation I’ve found so far seems to be:
https://www.wpbeaverbuilder.com/support/q/support-for-advanced-custom-fields-5-fields-in-widgets/
I wonder if you could confirm that this is a plausible explanation.
After a little research, it sounds like most page builders (and there are at least three where folks have asked why piklist does not working with their builder (I’d have to search again to find them more specifically). In the SiteOrigin case, they have one developer on the builder but it was mentioned that they would be happy to talk about the cause if someone from piklist were to have a conversation.
So here’s my take (and I’m not asking for anything other than your thoughts here):
1) The builders seem to expect some kind of client-side entity/class reference/name which they use to instantiate widgets?
2) Does this imply JavaScript code?
3) If I wanted to generate suitable client-side code what would it look like? I don’t have enough experience with standard widgets to know what their life-cycle (by this I mean the life-cycle sequence – creation, initialization, data hydration, execution, rendering, cleanup, etc). just yet but I can maybe dig around a bit.-
I found a little time to walk through some off the piklist code (only about an hour so my understanding remains limited). My previous questions may have been naive but I as I looked at the widget-related code in piklist, it dawned on me that the key difference between widgets that work in the page builders is the way piklist wraps the selection of a piklist-specific widget inside the Piklist_Universal_Widget.
Is Piklist_Universal_Widget the only widget actually registered with WordPress? (Parts/widget declarations are actually hosted by this widget and their methods – ie: form, update, widget) are delegated to the declared code inside a piklist-enabled theme or plugin).
In the SiteOrigin builder the inserted Widget is referred to as “Untitled Widget”.
The debug logs show:
[07-Jan-2016 22:43:51 UTC] PHP Notice: Undefined index: widget in […] class-piklist-universal-widget.php on line 157The builder renders a truncated string that looks like this” “scription_wrapper][field_description][/field_description_wrapper]”
I instrumented the $instance references before and after the call and found that in neither case is the $instance[‘widget’] value present. I suppose this implies that the previous $this->register_widgets(); call (in the widget function) is not correctly fetching the (virtual) widget.
I’m not sure if any of this helps lead to any particular next step but let me know what you think and I can take investigate to take this to the next level, assuming any of this is helpful.
-
-
This thread is intended to help you by investigating as much as I’m able to so you don’t have to and you can simply point me in the right direction to take a deeper look.
In the previous topic post, which was closed, you said “Finally had a chance to look at this. It doesn’t look like Page Builder is doing things the WordPress way, so we won’t be able to support using Piklist Widgets.” and then the topic was closed.
When you responded to this thread you said “We haven’t even looked at this issue…”.
What did you conclude when you responded to the previous thread? These statements don’t, at least on the surface, seem to be consistent so I wonder if you could just say a few words about what you already know about this problem.
-
I had actually gotten pretty far into implementing piklist on a new site, and was loving the convention-based file structure that I can check into git, but the wonky widgets are a bit of a non-starter for me. It’s frustrating because it’s so inconsistent with the well thought-out design of the rest of the framework.
I don’t work for SiteOrigin, but it seems disingenuous to say that it is the one doing things the wrong way when obviously the piklist widget method is a bit of a hack that wraps everything in a single registered global widget. I would be more than willing to contribute to a solution, but I think the attitude that all the page builders are just wrong is probably not conducive to actually fixing the problem.
-
- You must be logged in to reply to this topic.