What extensions the Pinegrow team is working on

Plugin Development
1

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.

9 Likes
2

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.

1 Like
3

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

4

@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
5

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.

6

@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.

7

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?

8

@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
9

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

1 Like
10

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

11

@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.

12

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.

13

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

14

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>
  <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>
  </div>
</div>

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.

15

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.

C

16

@matjaz,

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

:thinking: :crossed_fingers:

17

@RobM

Sorry this took so long. With all that has been going on lately it slipped my mind.
But anyway, nog that I’ve picked it up again a few days ago, I have familiarised myself a bit more with static site generators, Jekyll in particular. And I’ve made some (admittedly crude, sorry…) images that I think protray the concept that I have in mind reasonably well.

The first one is mainly inspired by the “content” action of the wordpress plugin and is analagous to it.
The idea is that it basically does the same thing as it defines header and footer files inside the page. Whether this is the best approach for a jekyll site in regards to Pinegrow, I don’t know but I thought that retaining similarity between jekyll and wordpress builders may be a good thing as many pinegrow users will already be familiar with the concepts employed.

Group 4
Group 43762×1916 293 KB

The second image is in regards to the blog posts (as jekyll is a “blog aware” SSG).
This particular piece of code was copied from Jekyll’s documentation page.
In this instance it’s a for loop that inserts a bunch of HTML into the page for every data entry in the file that is referenced there.

Doing it like in the picture below is similar to the “show posts” action of the wordpress plugin, and is supposed to work similarly.

Middel 2
Middel 23523×1698 270 KB

Here it shows that the “posts” jekyll action corresponds to the for loop (at least, how I envision it).

Group 6
Group 63967×1911 310 KB

And in this image, it shows the elements where the post link and the post title are placed by the jekyll “post-link” and “post-title” action on the element inside the for loop of the previous two two images.

Group 7
Group 73175×1471 172 KB

how this will work together, I’m not sure. Seeing as the wordpress plugin from pinegrow exports to PHP, in analogy something similar should happen to the Jekyll html files. The thing is in this case, HTML would export to ….html…. but with the liquid tags inserted into them. Perhaps this approach could work by helping the user “manage” their Jekyll file structure by defining wether the file is a template in something like “jekyll page settings”, similar to the wordpress plugin. When defined as a template, pinegrow could than export the files to the layouts folder wherever the jekyll project has been created, keeping the pingrow original files seperate (even thoug both would have .html extensions). Example in image below.

layout
layout3197×1899 188 KB

Alternatively the jekyll html files could perhaps somehow remove the liquid tags when opening the files in pinegrow (perhaps storing the data relating to this in a pinegrow.json file as is the case in the wordpress plugin, I don’t know, just thinking out loud here…) but will actually show the liquid tags when opening it in any other editor. However, this would require a different solution for the header and footer files.

Anyway, the main thing why I would like something like something like this because it would allow the excellent visual editing for a static site generator which otherwise doesn’t suport it.

I hope what I wrote here makes sense and doesn’t come across as too ramble-y.

1 Like
18

Sorry for the delay. There is a lot here to take in and think about. I think this is involved enough that we should take it to a new thread. I’m rather afraid that we thread-jacked this one! When I finally get time I’ll start a new one and tag you in it.

1 Like
19

Yes it does seem that way. Ok, I’ll await your tag.

20

Hello Matjaž,

I did take advantage to extend my Pro license and I’m about to work on few themes for Nikola static-site-generator and it is the time to think about which framework to use…

Yes, Tailwind does look interesting, but wonder if you can share some info how is your prototype integration going on and/or whether we can expect to see something in the foreseeable future?

I see that BS-5 alpha is out, but maybe UIkit plugin is also an option for less-bloated framework…