Initial Impressions and Thoughts on the Pinegrow Web Editor

We’ve recently completed a project to move an older Elementor and WordPress-based website over to a WordPress website with a custom theme and some custom WordPress blocks. And to do that, we used a tool called the Pinegrow Web Editor, and I’ve had a few people ask me about this tool. They asked why I like it and how it fits into my workflow. So, I thought I’d create a little video explaining all of that.

Most of the sites we work on are done inside the Oxygen builder in WordPress. We do some sites using the WordPress Block Editor (Gutenberg), and we’ve got some older sites in Elementor that we’re moving away from.

Challenges:

One of the big challenges that we have is with Gutenberg, in that it combines content and design, which really gets away from the way that CMSs are supposed to work, where they’re separate where you can change the pictures, you can change the text, you can change some basic formatting, but you’re not going to mess with the overall design of the site or of the page. The WordPress block editor turns all that upside down in making everything a block. Any editor can come in and really mess up the way that this page looks. They could start deleting elements if they wanted to, they could add an element they could add an accordion or a video or whatever, and there’s really no way to govern those changes or to manage them at all, especially when there’s multiple editors involved and change processes, and marketing departments and things like that.

The second problem we run into is vendor lock-in just like with page builders and other things. We now rely on third-party blocks to change the way that the site looks. Let’s take a look at things right now with the blocks. We’re using GenerateBlocks and Kadence blocks on this. If we deactivate those blocks, suddenly the site just doesn’t look quite as good. If for some reason, these blocks ever start having problems, or we need to move away from them for any reason, or if we’ve gone to other blocks and we don’t want to license these particular ones anymore. We’re kind of stuck you using them whether we want to or not. And unless we want to redo the whole site.

The other problem we have is block overlap. So many of these block sets have similar blocks and it gets very confusing for editors. For example, if I want to create a headline, I’ve got three different things here to choose from. I’ve got the standard built-in WordPress heading. I’ve got one from GenerateBlocks, and I’ve got one from Kadence. The client doesn’t know which one to use each one of these functions differently. They have different features. They all behave differently. There’s also no way for me administratively to turn blocks on and off for everybody on the site. I can do it for my own account, but I can’t do it across the board.

Oxygen also has its own problem. Its biggest issue is that it’s over-reliant on third parties to do even the most basic things like right-clicking inside of here doesn’t work without something like Hydrogen Pack installed. It doesn’t have any native design sets or frameworks built-in so we have to rely again on third parties to provide those. And each of those third parties, they’re small companies and they may be around for a long time, they may not be, they may support their products for a long time, they may not. And you know, what happens if one of these companies goes out of business and is no longer working with the latest versions of Oxygen, what happens if one of these third-party things starts breaking the site? Those are all just issues when you’ve got multiple products from different vendors that all come together to make up your ecosystem.

For example, my Oxygen toolbox has six different elements. It starts with the Oxygen builder itself, and then we’ve got the Oxygen Gutenberg integration, and then I’ve got OxyMade so that I have my Tailwind CSS classes to use. And then on top of that, I have OxyExtras to provide some certain tools that don’t come built in. Oxy Toolbox fixes some bugs inside of Oxygen. And then we’ve got Advanced Scripts. Since Oxygen takes over the theme inside WordPress, we need a script manager just to do simple things like running PHP scripts. So that’s a lot of tools. That’s six different tools from different developers that all have to work together to make our Oxygen system function the way that we need it to for the client. If any one of those pieces breaks, the website starts to break.

What I like about Pinegrow:

So, what is it that I like about Pinegrow? First thing is that Pinegrow is a visual development environment. It’s not a page builder. What we’re doing here is we’re creating standard CSS, PHP, and HTML files that we would use anywhere, that can be edited with any tool, and then brought back into Pinegrow or imported into WordPress and used just like you would if you were coding with Visual Studio or anything else. So that’s the first really nice thing.

Pinegrow is also great in that it lets me create custom themes and custom blocks to use inside of WordPress. And it lets me do it in a visual, very similar to Oxygen. So Pinegrow looks an awful lot like Oxygen, and it functions an awful lot like it in that we’ve got our main canvas here. And over here, we’ve got all the different elements for the page; we’ve got all our controls, and you can see with each thing that I click on that I’ve got all the controls available to me. I can change my spacing. I can change my flex containers. I can change my text, anything at all. I can change it. And I can do that here using my framework classes, on this tab, or I can come over here and create my own classes. And you use the same exact tools to do that.

Speaking of framework classes, I love the fact that this lets me use standard frameworks like Bootstrap and Tailwind. So those are things that they sort of have to emulate inside of tools like OxyNinja and OxyMade. Here, they’re just native and they work just like they would in any other development environment. So that’s fantastic.

The other thing that’s really special about this is that it lets me do mobile-first designs. For some reason, very few WordPress-based tools use a mobile-first methodology. Google recommends mobile-first, just about any other development environment for the web uses mobile-first, for some reason, WordPress doesn’t let us do it. So we always design using the smallest breakpoint first and then make changes as we go up instead of vice versa.

There are also no restrictions as to what we can do since this is just standard HTML and CSS, we can use JavaScript here, we can find tools and widgets and plug them into the page and they just work. We don’t have to rely on making sure that they work inside of whatever builder we’re using. We don’t have to say, does this slider work inside of Elementor or Oxygen or Bricks or Blocks or anything like that? If it’s a JavaScript slider it’s going to work in here.

The fact that Pinegrow exports things as themes and blocks and lets me bring them into WordPress and do exactly what I wanted before. So each of these different elements, these are all custom blocks that I made inside of Pinegrow, and just clicked the export button and brought them into WordPress. And you can see we’ve got this custom block that I can change the picture. I can come in here and change the text using the block editor. Same thing down here. I can change multiple images here for this particular block. And even over here, we’ve got a block within a block. So this is a repeater-type block within this bigger one. The customer can create as many of these steps as they want; changing the color, changing the text, changing the background, image, all those kinds of things. They’ve got complete control over this, but it’s not a third-party block. It’s not designed to work in a thousand different use cases. So, it’s a very effective code, very efficient code.

And it also doesn’t rely on and third-party themes and plugins the way that things have started to inside WordPress. So you can see here in my plugins, I’ve got nothing related to design or the block editor at all. I just have the basic things that I need to run. The site. Everything that we need is right here inside of this 1.5 Megabytes theme that contains the images, contains all the code. We need contains all the blocks that we need to run that site and to build this whole site. So very, very efficient.

Pinegrow Concerns:

I do struggle with some things. First of all, it’s not a widely used tool. It’s been around since 2014 and it’s worked with WordPress since about 2018, but there’s not a huge community for it. Like there is with Oxygen, Elementor, other mainstream tools.

There’s also no add-on ecosystem. Things like Oxygen are fantastic because I can go off and I can purchase a tool like OxyMade for frameworks or OxyExtras to get all these different types of elements that aren’t built-in. And that’s not something that we get here inside of Pinegrow. We get HTML, we get CSS, and we have their interactions add-on, which lets me do some animations. That’s kind of nice but we don’t have things like, tabs, we don’t have all those extra things that are just easily purchasable in other places. So where we do want those, we have to rely on blocks and we can very easily just tell one of these things to let us use a block in the design. But, we don’t have it built right into the builder itself.

There’s also a very steep learning curve. It’s not easy to outsource work in Pinegrow to freelancers or white label companies because chances are they haven’t worked in this, or they haven’t worked in it enough to be effective. It’s one thing if I want to train my team on how to use it because they can come in, we can all do the same thing, but the minute I bring in third-party help or hire somebody new, there’s some ramp-up time that needs to be considered.

Conclusion:

So, I guess the question is how does this fit into the way that we deliver websites for our clients? Right now, we’ve got two different ways that we do things. We use the block editor and things like GeneratePress or Kadence. And then we use Oxygen for most of our websites. I see this as potentially replacing Oxygen as our primary tool and us moving Oxygen to our number two tool.

We keep using block-based websites for the very simple things where it’s, you know, one or two people that need to do the edits, and the design’s very simple. It needs to be fast, lightweight, and with no fuss, no muss. We’d use Pinegrow for most everything else, where the design isn’t changing very often. And it’s just the content that changes. It takes about the same amount of time to develop here inside of Pinegrow and as it does inside of Oxygen. Then we would keep Oxygen around in our tool belt for those clients that need to have design changes more than two or three times a year or those clients that want to make design changes on their own. There’s definitely a place for all three of those tools. And I definitely see a place for Pinegrow going forward.

I hope this was helpful and please feel free to reach out if you have any questions at all. I’m happy to answer them.