Tailwind include 3rd Party Blocks in Purge

Feature Requests
1

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