What extensions the Pinegrow team is working on

Now that we invited developers to participate in developing Pinegrow extension, it’s a good idea to coordinate a bit in order to avoid multiple people/teams working on the same thing.

There is no problem in having many people trying to crack the same nut, each with their own approach and confidence that their solution will be the best - as long as this is an informed decision based on the awareness of what others, and especially the Pinegrow team, is doing.

We want to avoid situations where a developer would be creating extension for X and at the same time we would also be building the same feature, whereby decreasing the marketing potential of the developer’s extension.

So, for the sake of transparency, these are the extensions that Pinegrow team is currently building or planning to build in the near future:

  • Tailwind is gaining in popularity, so we are building a prototype integration to see well it could work with Pinegrow.
  • Support for responsive images will be implemented as a core Pinegrow feature.
  • Improved Blocks / Components where it will be possible to have per-component style / JS and only include that in the project if the component is actually used. This feature will also make it easier for other developers to create libraries with reusable blocks / components.

This is not the exhaustive list of what we’re doing, rather it’s a list of features that we are building that are good candidates for implementing as Pinegrow extensions.

And if you’re in doubt how the extension that you’re planning to build fits into the Pinegrow roadmap, just ask us about it.


Just to bump in here in case any experienced developers planning to build extensions for Pinegrow are watching this thread. I’d very much appreciate a Jekyll builder plugin for Pinegrow that is similar in execution to the native wordpress plugin. Personally I can work with the traditional command line interface of Jekyll (or, at least, I’m confident I can figure it out) but in my opnion this is a littlebit cumbursome to work with and I’d much rather integrate it into my existing Pinegrow workflow. Static sites have, in some specific cases, advantages over server driven sites (such as wordpress) and I’d like to offer this as an option to my clients. As it stands though, working in the command line would make such a project excruciatingly painstaking and it would also take longer to create than to make a simple wordpress theme with Pinegrow (which kind of negates the advantages these static sites can have) at least in my opinion. A Jekyll builder (or any other static site generator like Eleventy, Hugo, etc… For that matter, I’m not picky) for Pinegrow will change that though.

@Roel who would work with the site in Pinegrow: developer or the client?

@matjaz I’m not entirely sure what you mean but the developer (that is, me) would work with the site in pinegrow, as I was refering to a potential jekyll plugin to be a development tool (like the WP plugin) as this would allow buildng the Jekyll site visually (which the command line nature of Jekyll doesn’t really allow for). For instance, defining headers, footers and body content as the wordpress “the content” action does in the wordpress builder. The client (at least in the scenario that I have in mind) would work in a static CMS (ideally) like for instance Forestry.io. Which is configured using Front matter (so the site could be made compatible using a potential static site interface in pinegrow which would presumably contain an action element to configure front matter seeing as it is an important aspect of static site generators). As I understand it, static site generators (or, at least Jekyll) are pretty similar to wordpress in the way that they handle data structures as there is usually a main “blog” data type which can be expanded by collections (similar to custom post types in Wordpress). So I imagine a Jekyll builder for Pinegrow (that would be ideal for me) to work in a pretty similar way to the pringrow wordpress builder, with the principle difference being that Jekyll generates its pages beforehand, instead of on server request (as static site generators do).

Off course, in a different scenario, I can see a client working within the built in pinegrow static CMS that is made compatible with Jekyll and can press a “build jekyll theme” button similar in concept to the “export wordpress theme” button in the wordpress builder. Though, the fact that the pinegrow built in static cms can only be used locally and doesn’t support a built in FTP or GIT push interface, makes this option (at least, in my humble opinion) not as valuable compared to the above scenario where you would use an online static site CMS such as Forestry.

1 Like

Just thinking out loud, but Jekyll is Ruby based. I think delivering a plugin that could add Ruby in a platform-agnostic manner might be difficult.

@RobM Not necessarilly. I don’t expect (nor think it would be a good idea) to add Jekyll functionality directly to Pinegrow (as Pinegrow is javascript based). However, linking the templating language Jekyll uses, namely Liquid, to Pinegrow in order to have a jekyll file generator may I think be feasible.

For example. In Jekyll you can use a piece of liquid template code to connect a header file to a “index” template. However, when using pinegrow in conjunction with Jekyll now (which you can do as they are just plain html files) means you will not be able to see the actual header but only the exact liquid code added there (as if there were a paragraph there). Meaning your header lives in another file. What could be done, I’m thinking, is to just make a html file in a given folder where you just create a standard webpage and then add liquid code through means of “actions” similar to the native wordpress plugin. Which then convert to header, index and footer files repsectively when “exported”, to another folder of choice. These files can than be manually build using the command line, or deployed on a static site hosting service like github pages or Netlify and let them handle the build process (which is my prefered option).

Just my two cents though. Feel free to poke holes in my reasoning if you feel it is necessary. I’m not that well versed in static site generators (yet) but to the extent of my knowledge it does seem possible to integrate it in the way I described above.

I guess for that aspect, all that would be needed is for PG to recognize the “server-side” code in the page, like php. So, support for {{ }}, {% %}.
Are you thinking PG would pull the include files in and display them?

@RobM hmmm… yes and no, depending on how one would choose for such a plugin to work. I’ll try and illustrate it somehow. Give me a bit of time, I’ll try and get back to you as soon as possible when I’ve visualized my thoughts.

1 Like

Quite enough to justify my usage of Pinegrow and extending my (Pro) license. :wink:

1 Like

Is there any thought of adding Vue JS to the list of supported frameworks?

@matjaz thanks a lot for the shout out and for doing this for developers. Sounds like good plan. From my perspective, especially with Bootstrap 5 on the way, I would like to update my blocks plugin by combining the plugins I created into one plugin focusing purely on blocks and rebrand my site to focus on one plugin.

Improved Blocks / Components where it will be possible to have per-component style / JS and only include that in the project if the component is actually used. This feature will also make it easier for other developers to create libraries with reusable blocks / components.

This is what I would really would like to move to, but have not been able to crack it so I will b watching with great interest. With this feature I could add a lot more blocks without bloating the end result for users.

Tailwind does bloat HTML with classes though. It’s something that Tailwind enthusiasts seem to (consciously) overlook. It is as bloated as adding lots of inline CSS with the style attribute.

@Robert Yeah - the base file is pretty huge. They recommend that you use it with something like purgecss to slim it down.

Yes, you’re right. But that’s an other issue which you also mention the solution for.

What I meant was the many Tailwind classes that need to be added to HTML elements with the class attribute. Maybe because lots of Tailwind classes are just a single CSS property.
The following HTML snippet is displayed at their front page. Just look at the number of classes on the anchor element and the div just preceding it. And this is a really simple snippet not doing anything fancy.:
Five classes on the div-element to get the font right.
Four classes on the a-element to get the font right.

<div class="md:flex">
  <div class="md:flex-shrink-0">
    <img class="rounded-lg md:w-56" src="https://images.unsplash.com/photo-1556740738-b6a63e27c4df?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=448&q=80" alt="Woman paying for a purchase">
  <div class="mt-4 md:mt-0 md:ml-6">
    <div class="uppercase tracking-wide text-sm text-indigo-600 font-bold">Marketing</div>
    <a href="#" class="block mt-1 text-lg leading-tight font-semibold text-gray-900 hover:underline">Finding customers for your new business</a>
    <p class="mt-2 text-gray-600">Getting a new business off the ground is a lot of hard work. Here are five ideas you can use to find your first customers.</p>

I’m worried about the performance of Pinegrow having to maintain so many classes in one file. Let alone many files. And also about the size of the Pinegrow Style panel. But I don’t want to go off-topic too far. So I’ll stay quiet.

Looks interesting this Tailwind. Though I think It is a framework looking more toward backend developers and some front-end but propably not much appealing to web designers.
It gets you up and running just by looking at their classes references guide. A backend dev with little understanding in css or no interest on it can make it all the way to the end of a project without thinking on a styles css which is a “good” thing if its what you need.
However the code is tightly coupled both ways, the HTML depends on the specifics of Tailwind, making it very difficult to move or change in the future. Everything seems to be abstracted from the css putting the responsibility of appearance on the HTML, which it shouldn’t care about.
It looks like Inline styles 2.0.

It’s a good thing if PG include tailwind support. For me I rather start fron scratch or use the slimmer UI kit. For sure not bootstrap.



Will this improvement finally be somewhat relative to what was discussed back in 2016?

:thinking: :crossed_fingers: