Let me praise Pinegrow a bit

Pinegrow WP
1

Note: I am a big fan of Bricks and ACSS (and other Plugins). I don’t want to devalue any of these projects here. Nor do I want to upset anyone who uses these tools. After all, I use them myself.

I am just in the middle of building my second real-client Pinegrow Project.
Like many others I was overwhelmed by Pinegrow at first. But after seeing their WooCommerce Video Series i was sold.

After trying the Pinegrow WP Plugin first i was going to use the Desktop Application again.

No dependencies on runtime (aka “freeing headspace”)
For me the biggest point of Pinegrow is the fact that you are creating real WordPress Themes or Plugins by adding no extra layers of code-complexity. No dependencies after finishing the Theme/Plugin than WP itself. This is brilliant!

See, I am using Bricks, ACSS and Frames also for some Projects. That means in every Project my minimum Plugin/Theme Stack is:

  • Bricks (Theme)
  • ACSS Plugin
  • Frames Plugin
  • WPCodebox

This is a sum of 4 Plugins which will be often expanded by these plugins:

That means a sum of 1 Theme + 5 Plugins from 4 external Developers which adds long-time dependencies. Just for getting the visual Design of the Website done. Most of them never get touched after the Website is done, but they still need to be installed.

In Pinegrow Projects there is just my own Theme. No Dependencies to Pinegrow after finishing the Project. I can even copy the ACSS files in my theme and uninstall ACSS completely if i want to.

Development Workflow
Another big plus is that using the Pinegrow Desktop App your Project can be versioned with Git. Working in a Team is a lot easier then if every Developer is working on its local environment.

The exported Plugin or theme code also can be versioned with Git and easily deployed to a common dev-server that is accessible for the client.

This process gives you a lot of control.

Getting better as a Developer
I was a Drupal Developer and switched to WordPress because of its ease of use and speeding up project development. Also the commercial Plugin Environment is a big plus. On the other side i was getting more lazy and using more plugins than needed. This resulted in compatibility issues some times and debugging other peoples code even if i’ve payed for their Plugins. The more dependencies to foreign code you have the more fragile the system gets.

Pinegrow helps me to understand the WordPress core principles much better. I am forced to learn the template hierarchy. Also i was rethinking a lot of my CSS and remember how easy it can be to just add real CSS code instead of relying on visual tools. Even if Pinegrow does a fantastic job in syncing the style-panel and the css code, a am often open the style sheet and write my code directly. I am free to switch both modes while everything stays in perfect sync.

After getting familiar with Pinegrow I am not much slower creating my templates in PG than in Bricks or Oxygen. Okay, at this state i am still learning but I love the process to getting better with PG.

My biggest challenge will be a WooCommerce in the current Project - i am a bit nervous about that… :wink: I think this could be a part of the project that will need more time than in Bricks - maybe.

Client comfort
Even if some gets angry if others choose to give their clients access to the CMS… in my whole carrier the most projects needed to have at least a part of the CMS opened to the client (be it the website owner or its agency which I was hired by).

With Pinegrow i am free to create Gutenberg Blocks easily (ACF, PHP or even real JS/React). Really. It’s easier than ever.

No more complicated ACF or Metabox Setup for creating huge Forms which gives the client no idea how it looks on the frontend.

Yes, you still can do it that way. But now with Pinegrow i am able to create WYSIWYG Editor experiences without the risk that the content creator makes crazy design decisions.

Yes, i know that Gutenberg is crap in a lot of ways. But now having the power to build your very own project-specific blocks in a blink of an eye - that’s amazing. Thanks to Pinegrow this is now an option for me (i’ve build blocks with ACF and Metabox before and it was not a lot of fun and a lengthy process).

In my first Pinegrow Project i’ve tried to build Blocks and it worked very well (small site). The client is very happy with that. Now in the second Project i was able to build even better Blocks for a much more complex site (lots of grids and 4 types of accordion) and i am astonished how good this works. Here the client will not do content editing, but some third parties will. I am confident that this will work very well.

No restrictions
The HTML is mine. The CSS is mine. The JS is mine. If I want to.

And as it turns out its very easy to use beloved Plugins like WSForm or WPGridbuilder in combination with Pinegrow. In the current Project Ubermenu is used for Megamenu. No problems using any Plugin iI want because Pinegrows produces just plain WordPress Code and Templates. No abstractions. Breath freely!!!

Conclusion
Thanks to @adamslowe and the amazing Pinegrow Team I eventually learned to love Pinegrow after having a hard time learning (takes me two or three times to try it).

Here’s what i am talking about when praising easy editor experience:

14 Likes
2

That’s an excellent summary. I’m similar in that I have lots of experience with the various plugins/themes/builders like Bricks, Oxygen, ACF, Metabox, etc. but to be able to develop a theme which has no dependancies at all is quite remarkable.

As for Woocommerce, have you looked that this YouTube series?

I did the whole thing and loved it. I’ve not developed my own Woocommerce site in PG yet but I’m looking forward to when I do.

4 Likes
3

@MichelyWeb thank you for sharing your experience with Pinegrow! And for sticking with PG until the parts clicked together :wink:

5 Likes
4

great read and somewhere I am aiming to get to also.

Do you use ACSS/Frames etc with Pinegrow at the moment? How is the dev workflow?

i have been holding off attempting this myself due to wanting a bit more compatibility between everything so would be interested to hear how you are finding it

5

Hi @dan
i’ve created my own CSS framework on the go which is more stripped down to bare minimum. Mainly because i wanted to get a deep dive into clamp() and other interesting CSS concepts and refreshing my knowledge.

But if you want to use ACSS it should be relative simple: After saving your ACSS configuration there is a generated automatic.css file in wp-content/uploads/automatic-css/ that you can copy to your Pinegrow project or maybe even include with
<link rel="stylesheet" href="https://my-domain.com/wp-content/uploads/automatic-css/automatic.css">

This should work. The frames css can be found in same directory above.

For using frames you could import the frames to PG (could be with components or something), but that’s a topic i’ve not covered yet.

1 Like
6

Another option for ACSS is to copy the /automaticcss-plugin/assets/scss directory to your project (if you are using Pinegrow desktop), set your options in the “dashboard/options” file, then use Pinegrow’s Sass compiler to compile the automatic.css file yourself. That lets you use all the ACSS classes inside the builder and takes the plugin completely out of the picture.

** Double-check the ACSS license to make sure this is kosher, but the plugin says the license is GPL 2.0 so I suspect you’ll be fine.

2 Likes
7

Interesting. Wonder how you do the customizing of colors, spacing and so on? Are this just SASS variables? I will take a deeper look into this topic.

8

probably be an idea to install the plugin, set all your variables etc and then copy things to your project.

interesting thoughts @adamslowe will have to give that a go with the latest versions

9

@MichelyWeb, yes they are just Sass variables that get set with the ACSS control panel in WP. Extract the plugin and it’s all pretty straightforward.

@dan Setting the properties in the panel and then copying the CSS would work. The ACSS control panel just generates an automatic.css file that you can grab and use wherever you want.

10

@adamslowe if you are only using the Pinegrow WP plugin (PWPP) for block creation I take it the simplest way to use ACSS is via the wrapper settings you showed in your ACSS video or directly linking to the css file in the Index.html head tag?

Is the experience significantly improved by compiling (changed from running) the SASS in the desktop version of Pinegrow? Am I right to understand that doesn’t work in PWPP, even if you created the plugin first on the desktop version and then edited it later with PWPP?

I’ve never touched SASS to date and wanted to check first before going down that rabbit hole if not needed. My experience to date has been Winden + Bricks+ PWPP. I haven’t connected the dots for the css for frames @MichelyWeb mentioned. I am assuming Frames’s Gutenberg update might make that more relevant to PWPP when that happens?

11

You need to use the compiled CSS for automatic, not the SASS files.

I was not able to user frames with a Pinegrow Theme, because bricks generates the needed CSS for frames only if they are used in Bricks elements on a page. Seems there is no file with all CSS for all frames.

1 Like
12

Correct. The compiled Sass is the way to go.

For Frames, it looks like Kevin has the rules scoped to the relevant .brxe* prefixed classes on Bricks elements to specifically prevent them from being applied elsewhere. That’s a good practice, but it sucks for those of us who may want to use those components elsewhere.

Below is an example of the CSS for one of the components.

image
image1903×818 102 KB

.fr-feature-card-sierra__media-wrapper.brxe-block {
                order: -1;
                flex-direction: row;
                justify-content: flex-end;
                flex-grow: 1
            }

            /* BREAKPOINT: Desktop (BASE) */
            .fr-feature-card-sierra__image.brxe-image {
                height: 100%;
                object-fit: cover;
                flex-grow: 1
            }

            .fr-feature-card-sierra__image.brxe-image img {
                height: 100%;
                object-fit: cover
            }

            .fr-feature-card-sierra__image {
                aspect-ratio: var(--image-aspect-ratio);
            }
13

so if I am understanding this right. Compiling the sass in Pinegrow Desktop is no different from using the compiled CSS from Bricks in regards to how ACSS functions in the PD or PWPP?

14

The only difference is that the WP plugin uses the ACSS control panel to set the settings and variables in the Sass file. If you use the ACSS Sass files directly, you’ll have to go into them and change the relevant variables. I’m on mobile and don’t have the files handy, but it’s pretty obvious once you look under the hood.

15

Thank you, that makes sense now. I’m not using Pinegrow Desktop at this point so now I get where the SASS configuration comes in.