Maintaining blocks inside Sage or Radicle

radicle
1

Hi

Lets say there have been created 20 blocks inside Radicle or Sage and you have 100 websites. How would you organize your setup so that if some blocks needs gloabl fix (some WCAG for example) then you can push it across all websites with one push?

Maybe a separate plugin for all your blocks? Bad is that blocks are very integrated into theme (blade, vite etc)

So another idea is that Sage needs to be parent theme and maybe make 2 builds in parent - base stuff and 2nd build for blocks. And in child you dont override blocks build.

What you would do?

2

Can you post an example block to make it easier to visualize what you’re talking about + what type of fixes you’re talking about?

3

It can be that you are missing aria label somewhere for example and want to push this fix everywhere at once.

image
image193Ă—194 7.27 KB

For example here on swiper-button-prev aria-label is missing:

<div {!! $wrapperAttrs !!}>
  <div {!! $swiperAttrs !!}>
    <div class="swiper-wrapper">
      {!! $content !!}
    </div>

    @if($autoplay)
      @include('components.buttons.play-pause-video', ['type' => 'html5'])
    @endif
  </div>

  @if($showPagination)
    <div class="swiper-pagination"></div>
  @endif

  @if($showNavigation)
    <div class="swiper-navigation">
      <button class="swiper-button-prev">
        @svg('angle-left', 'icon')
      </button>
      <button class="swiper-button-next" aria-label="{{ esc_attr($nextLabel) }}">
        @svg('angle-right', 'icon')
      </button>
    </div>
  @endif
</div>
4

Pre-coffee brainstorming here. Maybe you can use some sort of symbolic links? That way the changes of one project would carry over to the other projects automatically.

Edit: Or you could make a folder that you can put it in, and make a script that moves everything in that folder into your respective component folders.

5

I like to have an agency starter template, in this case it could be Radicle with your 20 blocks included. Keep that in a git repo and clone each site from there. When you need to make a change to a block, you make it in your starter template and then merge those changes with each site. This seems like a safe option if you don’t want to move the blocks into a plugin.

1 Like
6

I would go the route of having all my blocks managed by a separate plugin, so you can update across all sites, assuming the markup for each block is always the same. You can actually tell Acorn to make blade available within your plugins directory using the following override in the config > view.php file, which you would place inside of your Sage theme:

'paths' => [
    get_theme_file_path('/resources/views'),
    get_theme_file_path('/resources/Blocks'),
    get_parent_theme_file_path('/resources/views'),
    get_parent_theme_file_path('/resources/Blocks'),
    WP_PLUGIN_DIR,
    resource_path('views'),
],

In this case, for my theme I load custom blocks for the theme within a custom directory of /resources/Blocks. You can also use WP_PLUGIN_DIR to have Acorn make blade available to any plugin inside of your plugin directory. Then you would just need to pass any necessary data to your block and render it using something like:

echo view("MyCustomPlugin/Path/To/View", $data)->render();

As far as CSS and JS, one option is to have the CSS and JS for the blocks live within the theme while the PHP and blade live within a custom plugin. This allows you to easily override CSS for each block on a per-site basis and have them work with Vite, etc.

Alternatively, there may be a way to have Vite load assets outside of the theme directory or have a separate Vite build process for files located in your plugin, but I haven’t experimented with this.

1 Like
7

You could make a plugin, but that might be unnecessary overhead. Personally I would create your own private Composer package with all your custom blocks, require that in each site/theme project, and then have a service provider within your blocks package that makes sure all the blocks and their static assets get enqueued through the normal Sage/Acorn boot process.

It might be slightly annoying separating the static assets (you’d end up having a separate Vite process in the blocks package). Still there’s a good argument for separating that stuff. Just plan the dependencies for scripts & stylesheets well :slight_smile:

(Edit: technically you could keep all your Vite stuff in the final site and just reach into the block package’s vendor folder to get the source files. That feels dirty to me but nothing would stop you.)

I don’t like child themes. They’re hacky and entirely unnecessary in a well-structured app.

I’ve done something similar on projects where I couldn’t use Composer or another package manager. The template project becomes the upstream master branch, each child project is created as a fork. Changes from upstream are pulled into the children with git. It works… but it’s fragile if you’re making changes in the children, you have to watch out for merge conflicts, and you don’t have the elegant separation of responsibilities that you get with a real package manager. If you do try this, keep a branch in each child project that tracks the upstream exactly without modifications — it will save you one day when merging!

2 Likes
8

You could make an acorn package which registers blocks and contains the views along with some base styles / scripts. As example, at the company I work at, we have an acorn package called wp-query-block (open source since last week). It only contains one block, but you could make a package which contains more!

3 Likes