Tailwind include 3rd Party Blocks in Purge

Hey there,

I’ve asked this in the live presentation of the Tailwind Integration too, but I thought when adding it as a feature request maybe some people see the potential of that and upvote it :slight_smile:

TLDR; What I’m thinking of is a possibility to include 3rd party blocks (mainly my custom developed blocks) in the tailwind purge. Maybe with a filter, maybe with another solution.

While it’s no big deal to just include the generated tailwind-styles in my custom block, it is every time a bit of an efford to disable preflight (since it’s already done by cwicly, but still in dev mode I kind of need it…), maintain the colors separately (what if a brand color changes for example I have to change it in cwicly and in my custom blocks), maybe prefix the TW of the blocks (not sure yet if thats necessary, probably not) and also having two stylesheets instead of one. Probably those stylesheets would have a lot of duplicated classes in it. So I thought it would be cool if Cwicly could provide us a PHP Filter to specify the blocks which should be included in the Tailwind Purge process. That would ensure compatibility with any other 3rd Party solution, but would still give us the possibility to add custom blocks to the tailwind Integration.

I’m thinking of something like this:

add_filter( 'cwicly/tailwind/block-list', function( $blocks ) {
  $custom_blocks = array(
      'core/paragraph', 
      'core/heading',
      'my-custom-block-1', 
      'my-custom-block-2',
      // Add more custom block names here
  );

   return array_merge($blocks, $custom_blocks);
}, 10 );

Not sure about the technical implementation of the purge, maybe @Louis can give more insights here…but if such kind of a filter would somehow be possible it would ease up the development for me, in my particular scenario, soo much. Hopefully there are others with a similar workflow / use case or other ideas of how we could create kind of a compatibility/extend the scope of the tailwind integration.

For clarification/more context, how I develop custom blocks:
I’m using Pinegrow for developing custom Blocks. Mainly for their Build-Process rather than using their UI. So what I’m doing is developing stuff in VSCode using Vite and React (or sometimes Vue) and then creating my Configuration in Vite in a way so that it generates Assets (JS) for all of my defined entry points. Then inside the PG visual Editor I create my custom Blocks (for each “entry point” in Vite I define one block) and use the assets generated from Vite to power the block with react/vue. In Combination with the wordpress rest API that gives me the Power to do almost everything inside of wordpress. It’s always more advanced blocks which I couldn’t do (or with a lot more work) inside of cwicly.

For Example I have one big client which has about 6 subcompanies. They invest a lot in hiring on a “shared level” but always branding on that global level the individual company. So I’ve developed a next.js Application with a custom express.js backend. I’m using that express.js backend to query jobinformation on all of the subcompany-sites. They do not need to be SEO optimized (since its only showing the “archive” of all jobs and redirects to that next.js application, and even if I would do a landing page some day, the canonical URL would still point to that next.js application) so I’ve done it in React with the described workflow above.

Another example is a Webshop I did, which has an Item “consultation” and if someone orders that item he gets a custom E-Mail with a link to his account page where another gutenberg Block (w react) waits and checks if the customer has paid that order. If that order is paid it shows a very advanced form (with image uploads to azure using the rest api). Since that consultation requires a lot of information beforehand and there is also some business logic running on it, I decided not to do it with a form builder… The Shop-Manager got their own page where they can see all open consultations and can edit them within their wordpress site. At the current state it’s a very basic form of editing which only allows updating the status, but in future it is planned to have the whole consultation workflow within that worpdress site.

Just to show some examples where a custom Block is needed… It is not a very big deal, but it would smoothen the sync of tailwind in all of these little custom projects, so one thing less to worry about and one thing more cwicly could handle (hopefully, somewhere in the future no custom blocks are needed within cwicly anymore :wink: ).

Cheers
Wolfgang

Hey there,

I just wanted to give that feature request another chance :wink:

I still think that this could be very beneficial to simplify development of custom Blocks. We are more and more switching over to headless systems like Directus with a custom Frontend since the development of stuff in Wordpress is such a pain. But I really want to use the editing experience in Wordpress.

With that combination I see so much potential in easily integrating complex blocks into Cwicly with tailwind. Thinking of stuff like custom appointment calendars and so.

Please upvote, if you can imagine that idea! :slight_smile:

1 Like

Hello @Wolfgang,

Thanks for bringing this up again.

I do like this idea a lot, and the process makes total sense.

Can you tell me how you’re currently referencing the Tailwind classes in your custom blocks? This would be the only part we’d need to make sure we’re properly accessing and filtering.

Cheers,

2 Likes

Hey @Louis,

Thanks a lot for your response. By referencing you mean how I include the tailwind Stylesheet? If so, then that’s the real pain point right now. I’m often creating blocks using pinegrow and really don’t create that much blocks with Wordpress npx command (I miss typescript there, and I don’t feel that comfortable with their implementation of react, at least as of the last time used it). So what I do is creating a react/vue/vanilla app using vite and then use the generated asset files to enqueue it on the block level (normally the block on that complicated apps is just a empty div used as starting point for that app → and by writing that I realize that I’ve maybe a mistake in my thinking - not sure if you’re even able to access the spa context on the editor site). Often i do also create custom blocks that don’t need a spa behind it and there it would probably work since they have the full markup available. However, integrating tailwind into the vite build is necessary in both cases since cwicly doesn’t scan those blocks…but to not infer with the cwicly styles it’s kind of complicated, disabling preflight, using prefix tools for tailwind and so on. More often the Result is not as accurate as in dev mode and it often needs further tweaking, that’s why I’m thinking that integrating custom blocks in your generation could help there. I could still easily setup tailwind on dev/local side - but just exclude it from the build.

I hope that helps in a way, and I’m very curious about your opinion on the SPA thing… don’t know how I could miss that important part of it in my initial thoughts. But maybe it’s also possible to scan the attached js file of the block, something like adding a node_modules path to the content property in the tailwind config … :smiley:

But being able to integrate mini apps (special when having no real php background but only node.js/javascript) on Wordpress is really a killer function, I very often use that to create custom dashboards on woo sites or to integrate with custom API endpoints (often also custom WP endpoints) for displaying data in a way that wouldn’t be possible (heavy interactive tables for example, and so on…)

Hope that helps?

Hi, to me this is a very important feature as well.
I rely on custom dynamic React blocks with TW and Vite/postcss and compatibility and single source for Globals, purge or all other conflicts should be clarified as much as possible.