From Pagebuilder (Bricks, Oxygen) to Pinegrow

Beginners
1

Dear Community,
I have been building websites with Oxygen and Bricks plus numerous plugins (Automaticss etc.). In the last few days, however, I have had some problems with the new Wordpress version and various plugins.

I would now like to reduce the number of plugins and the dependency on various page builders. In Adam Lowe " Pinegrow is Not a Page Builder" I got some information. Unfortunately, I’m finding it very difficult to switch over and set up the pages. Can you give me some tips on how to switch from Bricks to Pinegrow? In Bricks I worked with archive templates or created pages and then laid out the static pages or loaded data into the page with repeaters.

Would the procedure be the same here? Build a static page in Pinegrow and then connect the required elements (Wordpress blocks) or do I have to completely abandon the way of thinking when building, as in Bricks?

10000 thanks in advance for any helpful tips on the changeover.

4 Likes
2

The latest version of wordpress has a lot to answer for, the number of sites it has broken is quite staggering.

That aside, Pinegrow is a very different paradigm to the conventional page builders that you have been using and are used to. It is essentially and Html, Css and Js editor, but a rather clever one. Given that you have come here from word press then the odds are on, at least in the short term that you’ll want to stick with wordpress. @adamslowe has some great videos on you tube and I documented my own forays in this direction over on Github.

What I would urge to to consider is whether you actually need wordpress. You can create some remarkably complex static page sites and, as I am just discovering the sister product to Pinegow (Vue Designer) is rather good.

The more code that you can write yourself the less reliant on plugins you become and by extension the less likely it becomes that your sites (or apps) get brought down by third party code that hasn’t kept up with developments.

There are a lot of very friendly people here and way better at this than I am so you shouldn’t have too much trouble getting a feeling for how things work.

The small introductory tutorials accessible from the home screen in Pinegrow itself are great as the whole Woo Commerce course (which has a lot of really good info on word press in it).

I’d also strongly recommend the Pizzeria tutorial in the Vue Designer docs. That might well convince you that you don’t necessarily need to think that your only option to get to a website is Wordpress.

5 Likes
3

Thank you Dom,
I’ve just been to your Github. I’m working my way through the pages. The first step will be to understand wordpress properly :slight_smile: The next would be working with Metabox or ACF. These two work well with Pinegrow or do you not need them at all for simple things and can do this well with Pinegrow?

I have one more question. Does Pinegrow work well with Bricks? Has anyone here had any experience?

4

You on the right track first learning the WordPress principles. This is important to understand how to work with Pinegrow for WordPress.

You can use Pinegrow with Bricks together when you create a Plugin with Pinegrow and not a Theme. This way you can create your custom Gutenberg Blocks and use them independently.

I understand if you want to use Bricks for Header and Footer (escpecially for Menus) and Landingpages. But then you have still the dependencies.

My way in most projects is to create a Classic Theme with Pinegrow and include the Custom Blocks also in this theme. As a menu solution i use MaxMega Menu instead of building them completely in Pinegrow (when there is a need for Flyout- or Mega Menus).

Good luck. Don’t give up, you will be rewarded with a huge amount of knowlegde and very maintainable WordPress Sites when using Pinegrow.

2 Likes
5

Pinegrow and Page builders (Oxygen , Bricks etc) are not going to mix, they are completely different paradigms.

Currently you are thinking to yourself ‘I need some sort of page template, or post template etc, and where do I get those in Pinegrow?’ The simple answer is you don’t, where Wordpress is concerned the more accurate answer is you need to understand how WP itself works and then you can use Pinnegrow to create the basic templates that you need. That much I covered in those tutorials and you’ll also find a Video of @adamslowe doing something similar on you tube.

You can use both ACF and Metabox with Pinegrow of you can create your own custom post types within Pinegrow itself.

The fundamental shift that you are embarking on, although you may not realise it yet, is moving from a drag and drop type of experience in page builders that you’re currently used to to more of a hands on ‘write what I need myself’ approach. At first this can be very daunting but so long as you are prepared to start with really simple projects building really small often one page sites you’ll soon get the hang of how it all works (whilst at the same time becoming more familiar with Pinegrow).

The secret is to be patient. If you hit a snag ask.

2 Likes
6

Hang in there, once the PG team releases their full integration into the Full Site Editing experience it will be a lot easier to learn the switch to PG from a page builder. You’re on the right path if you want to reduce your dependency on plugins. It’s a bit of a learning curve but you’ll be getting much more flexibility and stability once you learn PG. -Best regards :grinning:

7

Personally, I’m heading in the opposite direction. I’m busy wrapping up quite a large project and I’ve found Pinegrow more frustrating than words can convey.

The menu system is a problem (there’s no simple multi-level default menu that isn’t broken for me), the Tailwind compiler doesn’t support @apply, the Mac app frequently freezes on me for a few seconds (I have an M1 Pro MacBook Pro with 32GB memory), the code formatting is garbage in the code editor (sometimes it looks halfway to being minimised) and doesn’t maintain my meticulous formatting, everything is a mission with separate script files, the codebase is littered with mentions of Pinegrow for no reason, a large project becomes challenging to keep organised, the default text styles are a disaster, and the latest I’ve discovered is that my compiled Tailwind file is incomplete. If I turn off the Tailwind dev CDN and rely only on my plugin’s generated styles, a chunk of my frontend is stuffed up.

It’s also not clear how one can provide any acceptable measure of control or access to templates for clients. A million toggles and fields in the theme customiser is not a good user experience. In the end I had to make a decision and switched from a custom theme to a custom plugin, and used the GeneratePress theme so that its excellent Elements templating features could be made available to the client.

I’m ready to throw my Mac out the window after this project. Never again. Straight back to Bricks and ACSS for me. This has been a nightmare, quite honestly.

Just my 2c. I’m sure many here love Pinegrow.

1 Like
8

@Bryn I can understand your frustration.

If I was being flippant I’d say , first and foremost, that the entire problem stems from relying on hardware with bits of half eaten fruit plastered all over it but then my views on on Apple machinery being overpriced junk are pretty well established across the web these days!

The struggles you’ve encountered remind me very much of when Microsoft decided to introduce WPF to the world, arguing that Winforms was simply not right for the then newer high resolution environments (paltry by today’s standards) that were coming in. Overnight one went from a drag and drop application building experience which was very much event driven to one where everything would be code lead and a visual designer that was (and still is some twenty years on) absolutely hopeless. I cannot begin to describe the pain that learning that new paradigm involved and the extra time it took , initially, to get anything done. However I persevered and I’m glad I did because it taught me one fundamental truth. At the end of the day everything connected with software is essentially nothing more than plain code.

Wordpress is busy undergoing its own Winforms to WPF moment at present and if the latest 6.4 update is anything to go by making a ham fist of it in much the same way that MS did.

My honest advice, for what it’s worth is to keep using Pinegrow (not necessarily for commercial projects where time is of the essence) because it is one of the finest enviroments in which to learn that fundamental truth taht at the end of the day all your are really doing is writing code. Pinegrow makes a great job of that, especially when combined with VSCode which is where you actually want to write the code itself.

If you really want to explore the next level then have a play with the new kid on the block Vue designer. That is an eye opener if ever there was one.

There are still a large number of people who still resolutely stick to Winforms but their numbers are ever dwindling. The same will be true of those who resolutely stick to page builders. Wordpress has made it’s mind up and is going to move to FSE. It probably won’t destroy it overnight but I think it will mark the point at which many people no longer turn to it first as a means to provide a website.

9

@Dom
My 16" MacBook Pro is the best piece of tech I’ve ever owned. It’s extraordinary. Pinegrow’s Mac app is the only thing that has ever had performance issues on it for me.

I haven’t seen anything yet with FSE that makes me think it’s better or even vaguely equivalent to what GeneratePress has already had for years, or what quality site builders like Bricks or Oxygen are capable of.

Web development isn’t just about writing code, it’s primarily about solving problems. And with Pinegrow I felt that I was trading one set of problems in for another. It’s not helping my clients to give them a black box that only the original dev can meaningfully interact with. With Bricks, the frontend output is flawless, clients can do basic tinkering, SEO and marketing agencies can create their landing pages, there is an incredible assortment of Bricks addons incl. the best CSS framework I’ve ever come across (Automatic.css) and overall development is so damn fast.

I love the idea of Pinegrow, I have enjoyed using GitHub on this project and having WP pull updates from GitHub automatically, but ultimately it is just too much mystery sauce and not something I’m comfortable taking ownership of with big ticket projects.

1 Like
10

I absolutely understand what you are saying, which is precisely why I said that for anything commercial you should, in the short term at least use those tools with which you are most comfortable because you will get more done.

Tools like Pinegrow, VsCode and its big brother Visual Studio (in which I spend most of my time) require, or perhaps a better term would be promote, a different mindset. You are expected to either know more, or at least be prepared to learn more, in order to use them effectively but once you’ve done that you will never go back and you will work way faster than ever you can with bricks or oxygen.

Github is its own peculiar world of pain but again once you’ve taken the time to learn how it works and made a good few mistakes in the process you’ll always use it because of the security that it brings when you inevitably break something irrevocably and need to retrace your steps.

This isn’t a my way is better than your way diatribe, at least I hope it’s not. More a plea to keep practicing with Pinegrow and other tools like it and use the opportunity to really get to know what is going on in the background. Once you’ve done that you’ll be amazed at just what you can do with mothing more than a keyboard and a good code editor.

11

@Dom I did study a BSc in Information Systems, I’m not that useless.

I’m not complaining that Pinegrow requires more custom code than a site builder like Bricks. I’m complaining that fundamental conveniences that I rely on - as a WP dev who has a lot on his plate at any given moment - seem to be missing or broken.

I have licenses to Alpine.js, Codyhouse, Tailwind UI, Flowbite, Shuffle and more. I was really looking forward to getting back into Tailwind and a more custom workflow. But as I said, I’ve found this project I’m busy wrapping up to be an exercise in frustration. I think I’d rather just have a custom project and rely on ACF Blocks, which are pretty quick to put together compared to React ones.

Regardless, I’m very curious as to why you’d say a custom workflow can be faster than anything else. I’ve never seen anything within a mile of the speed of Bricks or Oxygen, especially when using Automatic.css. Unless you mean mostly reusing the same components over and over again.

1 Like
12

Excuse me if I now ask as a beginner which basic amenities are missing. For me it’s just a question of understanding, because I’m in the process of familiarising myself with Pinegrow and HTML. CSS and JS and want to understand the basics. I also work on a MacBook Pro from 2018 and a Mac Studio M1. I’ve never had any problems with Pinegrow. I think Bricks and Automaticss are great, but for me it’s still a black box. I can see that it works, but I don’t really understand the background.

2 Likes
13

I didn’t mean to imply for a second that you were.

Component reuse is the key, the difference being that they are your components written to work the way that you want them to.

I know this isn’t relevant to Pinegrow but I in Visual Studio I rely on a tool called Coderush. Within that I have all sorts of templates called from simple two or three letter keyboard mnemonics that will out vast quantities of code to do all sorts of things.

As you have TailwindUI and Flowbite, why not take Vue Designer for a quick spin. That is really impressing me, particularly the speed with which you can put something together. True it’s yet another learning curve but it all helps to keep the old brain box active!

I can envisage a workflow where html is designed in Pinegrow and then converted into components in Vue Designer.

1 Like
14

Hi @Bryn,

All valid points, but as you can see this forum is mostly populated with Pinegrow fan boys and they don’t respond to any of your findings. On the contrary they keep on spreading “the word” without listening to your arguments.

I don’t even use Pinegrow for any static webdesign project (to much work). I find it only suitable for fast HTML prototyping (Bootstrap) and the use of Interactions that I find a brilliant app. Instead I use Codekit and Sublime text for pro webdesign. There are hardly any serious updates for Interactions or the normal page builder and it looks like it’s left behind. I’m afraid the same will happen with the Word Press plugin in the future.

David

15

@Bryn I am sorry to hear that you have a lot of problems running PG on your Mac. I had also some problems that went away after an PG Version Update. Now it runs smoothly.

I understand your pain with Pinegrow because i was there too. But then it clicked. Maybe you might find my post interesting.

If one prefers PG or Pagebuilders like Bricks might depend where you come from:
For people coming from a design and page builder background PG is hard to learn because it feels like PG turns everything upside down. You miss the made-for-you elements and all the bells and whistles from a Builder finding you in a Situation creating Accordions and Sliders by yourself instead of drag and drop them to the canvas.

If someone comes from a developer background and is already familiar with WordPress Theme creation, then PG adds comfort. It allows a more visual workflow.

I am building some Sites with Bricks and some with Pinegrow for now.
While the Projects built on base of a Custom Theme and Custom Blocks (built with Pinegrow) are very easy to maintain I often have problems with Bricks based Projects that are broken after Updates and then need some intervention.

If you want to do custom stuff you can have a lot of troubles finding solutions with Bricks too. For example if there are not the dynamic data you need (these placeholders in {}). Or if you try to add code to the body using ‘wp_body_open’ (WP default hook) programmatically and need several hours to find out that you need to use the custom hook ‘bricks_body’ instead (why??).

As soon as you leave the given trails it can get hard here too.

Like I said: use the tools thats fits your needs and that make you more productive. If its Bricks, good - if PG good too. If Elementor: no way… :wink:

It’s also not clear how one can provide any acceptable measure of control or access to templates for clients.

I do not understand this. Why would your clients ever need access to templates? I would even never do this with Bricks.

Oh and let me add: You can use ACSS and PG together. No need to use this overcomplicated Tailwind stuff.

6 Likes
16

@Bryn I hear your frustration and you raise some good points. There is nothing easy about Pinegrow, especially coming from the world of Page Builders, pre-made blocks, and block themes.

One of the things I had to repeat to myself over and over (and still do to some extent) is that Pinegrow is not designed to be a page builder or to compete with page builders. It’s designed to speed up the workflow for people who are creating themes or blocks by hand.

Think of it this way. Someone making the jump from Elementor to using Oxygen or Bricks is going to have a very bad day. They suddenly don’t have a lot of the pre-made components, design sets, etc. For every Bricks fanboy you see in the forums, there are likely many others who have tried it and noped out.

The move from a page builder to Pinegrow is even more challenging than that since now you are responsible for not only understanding HTML, CSS, and JS but you also need a solid foundation of how WordPress works under the hood, its core functions, and best practices for creating themes & blocks.

And on top of it all, the Pinegrow UI is not designed to be beginner-friendly.

However, for people who have been coding themes or blocks by hand, Pinegrow offers a lot of ways to enhance that workflow. Even for people who are just making ACF blocks, Pinegrow significantly speeds up and simplifies the process.

If you are looking for something that will be easier or faster to use than a page builder, Pinegrow probably isn’t it. If you want something that speeds up a manual development process, that’s where Pinegrow shines.

As for some of your other points:

I struggled with this, too, and complained to Pinegrow until I was blue in the face. They stood their ground, and after countless hours of beating my head against the wall, I finally understood why they chose to leave menu logic and styling to the developer. Menus, in general, are incredibly complex, and there are so many variations that trying to encapsulate them all in a wizard is a losing battle, especially for a developer-focused tool like Pinegrow.

FSE is a confusing mess at the moment, but it does have a lot to offer. With only a few minor exceptions, I’ve been able to recreate most of my classic themes as FSE themes. It’s a completely different paradigm from classic themes and page builders, so it’s a bit of a mental shift to wrap your head around working with it.

On the contrary, the themes and blocks created in Pinegrow can be opened and edited using any text editor. This is one of the biggest reasons I chose it for my agency; there is no lock-in. If clients need to make changes to theme templates, then this is where FSE can possibly help.

Also, remember that Pinegrow has a WP Plugin version, which will let clients or other agencies edit the project on the site just like you would in a page builder. From that perspective, there is no difference between it and Oxygen, Bricks, etc. other than the learning curve.

The internal compiler is not designed to handle plugins, @apply, or anything else like that. It’s meant to give you a bare bones tailwind config. For anything else, you’ll want to use the external tailwind compiler.

It’s also worth noting that Tailwind alone has a lot of quirks, and together with WordPress, they tend to fight each other. A lot! If you are trying to learn and use Tailwind while learning Pinegrow, you are going to end up frustrated.

Uncheck the auto-format HTML code setting in the settings window.

image
image840×78 4.73 KB

I’m interested in knowing more about this. There are references to pinegrow helper functions in the code, which are necessary to make things work, but I haven’t noticed any extraneous mentions of Pinegrow.

The text style issue is likely due to Tailwind, which has a very opinionated reset. A non-tailwind project has no default styles. As for keeping files organized, again, this comes down to a mind shift from thinking like a page builder to thinking like a theme/block development project.

I’m happy to discuss any of this with you. At the end of the day though, Pinegrow is just a tool. Nothing more, nothing less. If Bricks, Oxygen, Elementor, or WP Bakery fit your needs or workflow better, there is nothing wrong with that. (Ok, maybe not WP Bakery…)

8 Likes
17

This is an excellent summary for anyone considering Pinegrow. :+1:

4 Likes
18

The only thing I can add is I’ve also tried TailWind and WordPress together, and it was an absolute nightmare; they just don’t work well together because WordPress generates on the fly, and you’d have to have the entire TW library available (which defeats the purpose of TW) or try to generate TW styles in WP when posts/pages change which is problematic.

I agree about the menus not being versatile, so I just create my own way of doing that. Also, FSE has a whole new way of doing menus so eventually people will migrate to that or their own block way of doing menus (which I have done and have no limitations on my menus).

In the new FSE themes clients will have total control over templates or patterns directly in WordPress so that is something to look forward to. I’m already on FSE and look forward to when PG is upgraded to fully support FSE. FSE makes so many WP issues go away.

2 Likes
19

Trying to use Tailwind with WordPress adds an extra layer of complexity to the development process, and I’ve noticed it creates frustration among users. I feel that @Bryn struggled with this framework. You all know how it ends: everything becomes frustrating when one thing stops you from moving forward. I myself tried the external build approach, but it was too much work for a simple site that needed custom typography settings, though it’s nice to have that option. As @adamslowe mentioned, they do seem to conflict with each other. It’s unfortunate, as Tailwind really speeds things up. What about using Bootstrap? Is it considered outdated now? Perhaps Pinegrow should polish or update its Bootstrap UI/UX a bit more; it feels somewhat dated.

Regarding the menu issue, yes, menus can be a huge pain. @jonroc, could you share how you are tackling this challenge?

Pinegrow is not designed to be a page builder or to compete with page builders. Its purpose is to streamline the workflow for people who manually create themes or blocks.

I hope Pinegrow finds an effective way to integrate with Full Site Editing (FSE) amidst all these challenges becouse is a great of a software, but like everything in life, it has its Pros and Cons.

1 Like
20

Regarding menus: I am using MaxMegaMenu (free). Unfortunately it needs jQuery but otherwise it’s pretty good.