A quick question about best practice here if I may.
Working on a full site build with PG Desktop and plugin and documenting it all as I go. On my Master Page (index.html) I used PG interactions to make the mobile menu work.
I’m now working on the template for the static page (front-page.html) for which I will also require some interactions. Is this going to cause a conflict as I’ll obviously have to add them to the front-page.html in order to be able to use them?
Hi @Dom,
I just finished a full site build in PG Desktop doing pretty much what you’re describing and I’ve seen no ill effects. For reference, I used PG interactions for the mobile menu in the header and then also used them additionally for a slider block that’s used on the front page and it’s been working without issue.
If I’m not mistaken (and someone please chime in if I am), because you’re adding the header with the mobile navigation to the index page I’m pretty sure it’s adding PG Interactions through the whole site since the script is in the header. So unless you’re changing the header for individual pages in the Page Settings panel, like for a landing page or someting, it should be already loaded.
Hope this helps.
Hi @chipriggs
That’s exactly what I hoping will be the case. Thanks for your thoughts.
Having had a bit of a disastrous weekend on another aspect of the job front I’ve come back to look at this.
I have added a second page to the project and applied the master index page to it just for the sake of getting a screenshot. You can see PG interactions are added (to the index page) and in the section that I added to the Page html I added a div and a button to that. The button is currently selected but as you can see It still wants interactions to be activated.
A question for more experienced users. Is this expected behaviour?
I’m trying to see if it’s possible to build a dynamic Table of contents for blog posts (that I’d apply to the page.php template) and a scroll to the top feature both built with interactions and effectively piggy backing the interactions that were added to the index / master page.
Still have a lot to learn about the interactions so I don’t doubt I’m making some very stupid new user errors in my interpretation of what I think ought to be going on.
Hi @Dom,
I don’t remember having to activate Interactions on all the subsequent pages I created after making my index.html page, but I might have on the first one. Since I duplicated that page as a starting point for all the additional pages I made PG Interactions would of already been activated.
The rabbit hole of PG Interactions is DEEP! I’d recommend making an account on the Greensock website so you have access to their forums as it’s a great resource to explore the possibilities of what GSAP has to offer. @adamslowe tipped me off to that and I’ve been digging in and taking notes there ever since. I will say that being a bit more familiar with vanilla JS for things like mobile menus, modals, and such I’ve decided to continue using that method for needed interactive elements until I can find the time to learn more about GSAP & PG Interactions as I’m not comfortable using them on production websites with the limited knowledge I currently have about it.
Hi @chipriggs
Really good points you make. I thought I’d explore it because I want to write up the experience, the long term goal of the current project I’m embarked on being to demonstrate just what Pinegrow can bring to the WordPress development table without the need for additional plugins.
The use of interactions can be quite useful in that context, with the proviso that you keep it simple, at least to start with.
It is a remarkably clever addon but I can’t help but get the feeling that unless you really know what it’s capable of doing (by which I really mean that you need to know how to create the various interactions it’s capable of supporting , you’ll never get the full benefit out of it that you would otherwise.
Hi again @Dom
Yes! Pinegrow truly excels at cutting down the amount of third-party code through plug-ins that you need to introduce into your WordPress builds. Actually, that’s why I endured the sometimes steep learning curve of the WordPress export process through the app on my last project, which was actually my first production website built with PG. Unfortunately, something that would have typically taken me around three weeks with my old page builder process (Elementor) ended up ballooning out to several months but thankfully the client wasn’t in a hurry and I feel that the end result was worth the time I dedicated to the process.
That said in regards to Interactions, I’d have to agree with you as I often found it difficult to translate some of the tutorials that are available for Interactions through to using them in WordPress. @matjaz’s Flex tutorial is amazing and probably the only reason I was able to use Interactions at all on the project, so I hope eventually PG HQ ( 
) will produce more tutorials like that in the future since I feel the level of knowledge needed to really “color outside the lines” with Interactions in the WordPress context would take a fair amount of time to really master and could be sped up through tutorials like that.
@chipriggs noted, on interactions.
What the main things that held you back, that proved to be the most difficult?
Thanks!
For what it’s worth, and speaking from a purely personal perspective.
The vast majority of my day to day programming over the past few decades has been done in Visual Studio and its predecessors in the dot net (and again previous) sphere. Working predominantly in code and then often creating required components from scratch has been a major part of my programming experience.
For as long as I could I avoided web working ostensibly because my knowledge of HTML was sparse to say the least, and that’s before one throws in CSS and JS into the mix. Ergo when it became necessary to do do some of this new fangled (to me at least) web stuff I looked for as easy a way in as I could find, which turned out to be WordPress and Divi. Going to Divi from Visual Studio was ghastly, no control, no ability to properly reuse stuff etc etc. Oxygen Builder came along and at least felt a little more like it, and with some of the tools that have been developed to make it more developer friendly (such as a cli) it’s not that bad a way to do word press.
However it would be stupid to pretend that WordPress is not changing and most of that change is Gutenberg driven so having been badly bitten by the Winforms / Wpf saga I sought out alternatives , one of which was Pinegrow.
For a Visual Studia afficianado Pinegrow is just great. If I want to work just in code that what I do, moreover I can do that in VSCode if I want to. I can develop sites for wordpress but I’m not limited to WordPress, another plus point. Because of the ease with which you can work in code you are immediately open to (when working on a WordPress site) the possibility of doing away with all sorts of plugins that were almost a necessity with page builders because you can just code the functionality that you need. However this does come at the cost of a very steep learning curve.
To start with there is the whole Pinegrow ide to learn. As with anything else that comes with practice and familiarity but it’s still a significant investment in time. Then if you come to Pinegrow to do predominantly WordPress stuff from a traditional page builder you suddenly realise how much of WordPress (not least it’s byzantine template system) was being masked from you and which you now need to gain at least a good rudimentary understanding off. Once again it’s not exactly rocket science but it does take time.
Pinegrow’s documentation is good in that it covers a phenomenal amount and is backed up by a vast array of video tutorials but it suffers from, in my opinion, one major flaw. There is too much intermixing of Pinegrow versions in it. A classic case in point is the documentation on setting up external build processing with Tailwind.
To bring this around to the actual subject of this particular post. Logic told me that if I created a master page in Pinegrow for my WordPress theme based on the index.html / php file which in WordPress template terms is the ultimate fallback and that if I added interactions to that then logically those intercations would flow through to anything that was based on them. I couldn’t see why therefore I was being asked to activate interactions on new pages that were based on that master page.
That was not explained in the documentation or mentioned in any of the videos I watched. Now that doesn’t mean that information isn’t there just that I couldn’t find it.
It’s these little hiccups along the way that take time initially to resolve and then allow you to progress to the next step. Experience and familiarity with the way that Pinegrow does things will allow you to get faster, especially when you know exactly what the end result should look like in code, just letting you write it directly in code in the first place.
I love the fact that Pinegrow is giving me an opportunity to properly learn HTML, CSS and JS in a way that I hadn’t done before but I have to accept that whilst I’m doing that actual progress (in terms of start to finish) on a new project will by definition be slower.
I hope that goes some way to understanding my perspective as a new user to Pinegrow, For me I suspect that interactions will always be troublesome (basic lack of understanding). Yes it would always be nice to have examples of absolutely everything but one has to be pragmatic and appreciate that that simply isn’t possible.
Hi @matjaz
I’ll preface my reply with saying that a lot of the extra time spent on this project was my own making as I was trying to figure out a new, potentially Gutenberg block based workflow for designing WordPress sites moving forward so that involved trying out several other solutions simultaneously as the build I had going in Pinegrow. At one point, if I remember correctly, I had the front page of the project mostly built out in Cwicly, GenerateBlocks, Greenshift and Pinegrow. I used the front page as a test bed since it had a lot of elements that seem to pop up in client projects I’m involved with so if something was going to be an issue it typically would make itself apparent there.
Also, I feel another reason for the extra time was my decision to not use a framework of any kind and to roll my own design & styles. Having hand coded (somewhat hackily 
) WordPress sites with Bootstrap in the past and having to do CSS gymnastics to have it do what I wanted/needed it to I felt coding from scratch would help me eliminate most of that. Unfortunately, it was a much bigger lift than what I had hoped it would be due to the scope of the project.
So, all that said, we’re back to your question of “What the main things that held you back, that proved to be the most difficult?”.
First, I’d say that as good as Pinegrow’s documentation is, there are sections in the WordPress side of it that could use some help and also go deeper on certain topics. An example of this would be adding in your own PHP code to a WordPress build. Should you use the “Function” action with “Custom code” or a “PHP Code” action? After you make that decision, how do you format your code to work properly through Pinegrow verses the way it would be formatted if you hand coded it into the php file in WordPress yourself. This can be somewhat confusing and could really be elaborated on in the documentation even if it’s just a set of guidelines to follow. I understand that this is a somewhat more advanced example but one that I feel that people coming from other platforms (Webflow) and builders will eventually bump their heads against and need further explanation on than what’s currently available. Also, I find that there’s a lot of older tutorials from previous versions of Pinegrow that are a bit outdated and make finding what you truly are looking for harder to find so maybe marking things that are older as such or maybe moving them into their own section would be a good idea.
Second, in my opinion having a prebuilt library of plain HTML templates for commonly used things could go a long way in helping people move from other platforms to Pinegrow. Yes, you can bring pretty much any HTML/CSS layout you find into Pinegrow or use a framework like Bootstrap or Tailwind but all of those add another level of complexity into the process that a new user faces, especially when you’re attempting to translate that into a WordPress theme or block. Things like a small collection of header & footer layouts, a few simple grid based blog layouts, and common layout pattern templates based on flexbox and grid could help a new user get up to speed a lot faster. Pretty much every other platform that users will be migrating from have some kind of template collection and while Pinegrow does offer a lot Bootstrap & Tailwind options I’m not sure those are the easiest options for a newbie to use. Also, it would greatly tie into Pinegrow being a premier way to learn CSS Grid & Flexbox if combined with some video tutorials (I know the Grid tutorial is there but it’s a bit long in the tooth at this point). To pull this back to my own project, I feel like having something like this would have sped things up quite a bit since I’m not really breaking any new ground with the layouts I used but I still had to work them up myself which took a fair amount of time, especially taking into account having to work out the responsive aspects of each of them.
Third, and while this ties into the library idea above I feel it’s different enough to mention that a library of Interactions that are ready to go as WordPress Blocks based around commonly used interactions & layout patterns in WordPress would be very helpful. While I do agree with @Dom that one has to be pragmatic and understand that examples of absolutely everything isn’t really possible, I do feel that PG Interactions is a DEEP topic and setting them up for use in WordPress adds a level of complexity to things that I don’t feel that a new user or even someone with just limited knowledge in GSAP would bother approaching without examples and possibly some kind of tutorial or light documentation. I know in my own project after going through your Flex tutorial several times I was able to build out a slider and mobile menu to use but I could of just easily implemented an already built vanilla JS/CSS version of these found though a few web searches, not to mention the possibility of falling back on using plug-ins as a simpler, ready made solution. I was in a unique position with this project that I had the time to spend to do this but in a different situation I would of just used an alternative to save time and honestly ended up doing so for the photo gallery I put together by using a simple grid layout with links and a plugin to handle the lightbox side of it.
I completely understand that Pinegrow is built to be a professional grade tool but I see no reason why it couldn’t appeal to more visual builder WordPress users who want a better solution than what they’re currently using. Especially with the writing on the wall in regards to the direction that WordPress is slowly (and I mean slooooooooowly) heading with Gutenberg and FSE. I feel that to really bring in & keep more users Pinegrow it’s going to need more thorough documentation, tutorials like your Flex & WooCommerce ones (and what @adamslowe has been producing), and a library of framework-less starting templates to slack out the learning curve a bit. The tools are there and are fantastic but I fear that the learning curve might be a bit much for a lot of migrating users to handle.
Closing out, I’m super excited to see where Pinegrow is heading with the possibilities of a FSE Theme being worked in and other enhancements so a big THANK YOU is in order to you and the team for everything you’ve built out so far. It’s exciting times so hopefully what I’ve said above is viewed as things that could help grow the user base, community, & the advancement of the tool. Thanks!
Or maybe a side by side version comparison in column form?
YES! Don’t limit it to just wordpress though.
I, personally never really got anywhere productive with interactions, and then, never put the time and effort in to try and follow it up, so an interactions library would be fab 
@Dom @chipriggs thank you A LOT for your detailed feedback! It will take a bit for us to digest and translate it into action, but you should start seeing improvements soon. The low hanging fruit is creating more tutorial lessons, covering PG in a more systematic way.
@matjaz Always glad to help out when I can.
I will say that I can only imagine how hard it must be to weed through all the feature requests to filter out what is best for the whole rather than the one. I’m always trying to keep that in mind before I hit up any manufacture with suggestions as there’s always tradeoffs for everything that’s implemented in a product, whether it’s digital or physical.
Also, that’s why what I suggested above is more based around information (tutorials), documentation (structure), and additional tools (templates) to allow the users to find answers to questions, hopefully on their own, and also improve their experience by adding additional things without directly changing the core product at all.
