Advanced users - how are you using Pinegrow?

We have now started the project of improving the UI of all PG products, both in terms of usability and design.

Recently, we had a great topic on obstacles that new PG users face:

To make the UI really better, it is also very important to hear about the other side of the topic - how are advanced users [*] using Pinegrow, what features are the most powerful / useful for you, your use cases and workflows.

[*] A simple test of being an advanced users: if you run into any PG limitations you simply work around it in code, without giving it much thought.

In the quest to make things simpler for new users, we do not want to break or take anything away for our advanced users. Especially as such users might not be so vocal here on the forum, because you have figured things out and learned to live with any PG quirks without complaining about them :wink:

So, please tell us more about how you use Pinegrow here.


This is a large and complex topic, and I’m 100% positive I’m not going to be able to catch all my thoughts on how I use Pinegrow or what features are the most useful to me. So, I’ll list my main use cases for Pinegrow and try to organize some high-level thoughts about each.

WordPress themes and blocks

This is by far the thing I use Pinegrow for the most – creating classic themes and blocks. For the most part, things work very well, and I don’t have any workflow-related feature requests that I can think of. My biggest pain point when working on WP projects is creating the menu and/or page header. Even with a starter template, it’s just so time-consuming! Of course, adding a menu builder is a massive undertaking and arguably has no place in a product like Pinegrow, but it sure would be nice :wink:

Most of my WordPress work is with plain HTML & CSS (Sass) since frameworks like Tailwind create unnecessary friction with the WP Block Editor.

Pinegrow WP Plugin

I’ve been using this on smaller projects where I need to make more frequent changes to the theme or blocks. My biggest pain point is that Sass is not supported, so I have to use a modified starter template and different processes than I normally do in Pinegrow desktop. Additionally, the relative inflexibility of the built-in Tailwind compiler makes this far less useful than I’d like it to be. Version control is also more difficult in the WP Plugin and I find myself exporting projects to save them locally for safety.

Prototyping & Mockups with Tailwind

I use Pinegrow to create quick mockups and/or prototypes. It’s so easy to copy/paste components and templates from places like TailwindUI, Alpine, Flowbite, etc. As I mentioned earlier, the built-in compiler feels limited, and even using things like @apply directives are not possible since we can’t modify the input.css file. I think giving us even limited ability to modify the input.css and tailwind.config.js files would go a long way toward making it more useful.

As far as the external build process goes, it’s relatively complex, and the scattered documentation covering several versions doesn’t help. That’s part of the reason why I made a video documenting it. Creating a helper inside Pinegrow to automate some of that work and give people a default configuration to build on would be a huge help, especially to people who aren’t familiar with how Tailwind works.

I’m not doing much in the way of Application UIs or true components, so my views on Tailwind and how they relate to Pinegrow are from the perspective of someone building WordPress and static websites for clients.

Vanilla HTML/CSS/JS Projects

I’ve created a few static HTML/CSS/JS projects, and overall, I love the tools that are in place. I would love to see support for Open Graph properties in the HTML Header, though. At least og:url, og:title, og:description, and og:image.

Reusable Libraries

This has so much promise, and I want to use it, but in practice, I find that copying HTML and CSS from another “master project” is generally easier. The main struggles (for me and my tiny team) are that creating a custom library page for the inserter is more trouble to maintain than it’s worth and that the component styles are cumbersome to manage unless I’m using a utility framework like Tailwind. In my mind, having not given too much thought to it, I’d love a way to store each component with Sass partials and have the destination project simply add or reference them in the destination project. The current method of referencing the resources from the reusable library is fine during development, but packaging all the various resources for production adds another layer of complexity and hassle.

That’s all… for now!

I’m sure I’ll think of more as time goes on. These are the things that immediately came to the top of my mind.


Reusable Components/libraries.
This feature would be a real plus but getting it to work feels like extra work and not the other way around.
Tailwind Css
I tried to used it in two projects but at a certain point I had the need to modify the config.js file. You can’t. I jumped to the external build process (with all its drawback) but then css block stylesheet would not work correctly in my WP site… so things were getting a bit too complex for a landing page…so I dropped the two TW projects. Went with plain html and css for one and BS on the other


This got me thinking. I work across two computers (desktop and laptop) and use Git to keep both backed up and synced. Being able to store reusable components somewhere online - maybe a dev website which can be connected to via FTP to store all the components. Then you just put in the connection details to PG settings and can work with them from any computer.

I know this is a bit of a branch in thinking but thought I’d mention it as Adam’s post planted the idea in my head!


In the process of enhancing Pinegrow’s UI, my suggestion would be to maintain the essence of the existing layout to avoid disorienting experienced users, while also injecting a more intuitive and modern design aesthetic to appeal to new users.

Rather than restructuring the entire interface, it might be more beneficial to subtly refine the existing components, and improve upon the visual hierarchy. It’s essential that new users aren’t overwhelmed when they first engage with the platform. As such, creating an interface that is sleek, fresh and less cluttered, but doesn’t shy away from its inherent complexity could be the way forward.

Although it’s challenging to articulate precisely, I believe there’s an opportunity to make the complexity feel inviting, rather than daunting. This could potentially be achieved by implementing progressive disclosure, where advanced features are tucked away and can be revealed as the user’s skill level increases.

However, these changes shouldn’t undermine the experience of advanced users. Therefore, careful thought must be given to strike the balance between accessibility for beginners and the efficiency and power required by experienced users.


I’d like t add that I use Bootstrap for fast prototyping, but leverage Pinegrow’s smart components and master pages. They are very powerful, flexible and save tons of time building high fidelity prototypes that are consumable/usable by developers.


I use Pinegrow for nearly everything. I create static HTML websites for customers from the ground up without using bootstrap or any other framework. I create themes for Wordpress and WooCommerse. I also develop dynamic php Webapps like login areas and so on just with Pinegrow. It’s the ideal tool to combine the code with the easy to use visual editor.

I love the Interactions, I love the bootstrap Icons (maybe the icon sets could be updated, there are more icons offered by bootstrap now). I love components and how it’s done in Pinegrow (although it took some time for me to understand the define editable and optional thing)

I have a few little things on my wishlist: The input fields for pixel values (margins, padding, etc.) is quite small since the !important Icon was added right to them. It would be great if I could see the value “1000px” without cutting it up.

It would be great if we could move pages in the project tab into folders. When you do it (its not that often) I brings me out of my workflow because I have to open the website folder in the finder.

I think on main hurdle for new users is the name of the objects (img, p, a) you can place on the website. I came from a more easy to use Website tool and was forced to learn HTML when I started using Pinegrow (which is great, but maybe the learning curve is too steep).

I would welcome a new, more intuitive design but I really like the way Pinegrow works now, after learning it for maybe 6 months and I think the changes should be marginal.


I am using PG for creating classic WordPress Themes with Blocks or for creating Custom Blocks as a Plugin.

My quick wishlist:

  • I would like to have the option to replace the default breakpoints with my custom breakpoints completely
  • renaming Breakpoint with custom names
  • giving names to custom breakpoints
  • A more comfortable way to add custom image sizes to WP Themes in a fashion that can be reused in other projects. For now i do it in custom code, but then the image sizes are not selectable in PG UI and i have to type them by myself all the time
1 Like

Hey Team

I left PG because of the reluctance to help beginners. For me, I would use PG as a theme builder and create reusable custom blocks. The front end I’d like handled by Builderius.

I also believe that PG should appeal to both beginners and advanced users. What put me off is that I don’t know the WordPress post hierarchy. I’d like to create a block and easily assign a field type. Also create custom post type by clicking on a button called new custom post.

I think it’s not just about the UI but the UX supported by user friendly documentation. Not only appeal to advanced users but those starting off. It’s ok if you only want to appeal to advanced users. I can only say that at one point, you were all beginners. Teaching beginners adds value that currently only Webflow is doing. If you want the next generation, I can only say avoid terms like you have to be a developer to use PG but teach.

1 Like

I wonder if it’s possible to have 2/3 views. Basic, classic and modern view. PG team could add to the modern view and get feedback as they go along until they get to the point where the classic veiw is hardly used and turn it off. The basic view could be for begineers. I’m not sure if this is technically possible. I’d say build the new UI over time. Maybe build a basic view initally as a concept. @matjaz

You can use custom breakpoints in PG? Is this not possible for you because of a framework?

I’m not sure if this makes sense. Maybe a fresher UI with a little bit more explanation and more tutorials for beginners would do the job.

You can add custom breakpoints. But you can not name them nor remove the default breakpoints afaik

PG is a tool that helps you doing your craft faster. But you have to know your craft (how does WP function). PG is not a toy that tries to make WebDev easy for mom and grandpa - and that’s a good thing. It can be hard to learn the UI (which is overwhelming sometimes) but it’s worth it.


I used Pinegrow on a trial basis, initially for WordPress, but its use I find more useful for prototyping/mockup very quickly (compared to figma, Pinegrow makes more sense to me for several reasons). WordPress abandoned due to not full support for WooCommerce.

Menu, panels, icons

The learning curve of the program seemed a bit high, at least for me. Initially, I had to struggle a bit to remember the location of the items I was looking for within the various panels and menus.

With some menu items, I got a little confused. For example:
Components > Add resources
Page > Stylesheet manager

And I don’t understand why some items were repeated in different sections of the menu:
“File > Manage libraries & plugins”
“Page > Manage libraries & plugins”

The 3 icons, placed on the right side "Help, Power up with Pinegrow, Read News) are redundant, there is already everything in the “Support” menu, there is no sense to clutter the UI with elements (personal opinion) quite useless for the user.

However, after fiddling around a bit/read the docs, I appreciated the UI and the hard work the developers put into organizing all the elements so clearly. Everything made sense.

Page libraries

The reusable components section (Page libraries) a bit awkward. I am referring to the drag and drop components and blocks section. With the exception of "Blocks" made by you, the other libraries were really useless (e.g., Tailwind Components, Tailwind Docs, etc.). It may be useful for self-created libraries, but not for online libraries.

Many online libraries use the “copy code” button to copy the component code, it does not make sense to use drag and drop. Maybe giving the user the option to select via checkbox “not use any selectors, just open the page” might be useful.


Some times, I have found it a bit inconvenient to use and etc. in components. Many times there is no need for "Click here" text or similar placeholders, but there is just a need for the element, especially when you are designing nested elements. It might be useful to add, under the setting "Show placeholders on empty elements" another option to remove the inner html inside the elements.

Great to see some movement in this area! I was banging on about this specifically years ago!

I mostly use PG for static sites and JAMStack builds for a lightweight CMS. Occasionally WP with ACF and custom blocks.

  • I’d love to be able to use it with Jekyll or other JAMstack alternatives (more backend code options available)
  • Better integration with Webpack or other builders/A more defined workflow. Once I need to start bundling my JS together, I always feel like it turns my project to porridge
  • I can never get ‘pinning’ to work in GSAP editor and I always resort to code
  • Similarly, a more integrated way to add your own GSAP library to use with editor & to add plugins (I don’t expect to have an interface for all the plugins though)
  • To wrap elements in another element
  • drag/drop css blocks around to arrange specificity order plus a clearer way to know what’s more specific
  • Weirdly specific but when I open [+ Insert] I’d love the code block to be autofocus so I can just paste my code without clicking on the code area and a shortcut to open it
  • Built in minifier on selected code - I always unminify the pg code in the header and would like to quickly minify it again (or any selected bit of code), uglifier, capitalise too!

Oh, and there needs to be a way to opt into the new layout or maintain the old layout. This seems common place within the industry.

More tutorials would be great but I do think an overall of the UI would benefit new and some exisitng users. Satisfying both advanced and beegineers with different views could lower the barrier to entry. One think that I’m thinking is if I wanted to create a custom post type, it’ll be good if I can just click on new post type and it’s registered. While a different view for advanced who know what they are doing. Looking at the comments there seems to be a wide range of use cases. Mine would be theme builder with custom, postypes and custom blocks. I’d be using it just to manage content. All systing will be done by Builderius.

I’m thinking that it’s an opputunity to tackcle buth the UI and UX as a way to improve workflow. I do accept PG is a tool for advanced users. I was able to make a page and get it published. I was able to accomish it by taking parts from different YouTube videos made by pg. While the title is for advanced users, if you design the UI/UX for begineers the result could be make easier for advanced users. @fakesamgregory quite rightly said well over a year ago. If you select Grid or Flex why see the conrols. It’s an endless scroll. I’m also very keen to stress that advanced users flexibity should not suffer.

Because I read it several times here: I don’t think that it would make much sense to create several UIs for experienced users or for new users. I think it would be better to maintain advanced features (eg under a popup, botton or accordion) when a complex feature is simplified. We see that with the WP Smart actions. I love to use them because they are fast and easy to use. But in some cases I can always transform them to the old actions for deeper options.

1 Like