Add global header block

[iandunn]

this is a rough sketch of how repo-tools could contain the global header, with all themes could include in various ways

interconnected with WordPress/wporg-news-2021#20

see #6

if this sounds good, i'll add the rest

[coreymckrill]

What do you think are the pros/cons of doing it this way instead of creating a plugin or mu-plugin to register these blocks?

[iandunn]

pro: each site gets to pick and choose which components, blocks, etc it wants to use

con: components that get used on all sites still have to be included by other code

this way felt more natural, since i've been thinking of repo tools more like a library that provides a set of tools & reusable components, rather than a plugin that has context of where/how it'll be used. i don't feel too strongly though.

[coreymckrill]

this way felt more natural, since i've been thinking of repo tools more like a library that provides a set of tools & reusable components, rather than a plugin that has context of where/how it'll be used.

I was thinking of this like a library too, but one specifically for tools for repo management. I was not envisioning that this would ever get installed anywhere on production.

each site gets to pick and choose which components, blocks, etc it wants to use

I think you could still do this if it was an mu-plugin. Rather than having all of the blocks automatically load, you could have a function like wporg_load_site_blocks() or something that takes an array of blocks you want to use. (mu-plugin rather than plugin so you could always make the assumption that the loading function is available)

I'm not entirely opposed to doing it this way, but it feels... unconventional, and might be confusing down the road. Plus what I said about not anticipating it being installed on production.

[iandunn]

I was not envisioning that this would ever get installed anywhere on production.

Ah, ok, I think that's a good distinction to make 👍🏻

but then where would we put it? meta.svn/.../mu-plugins/pub ?

I guess we could create a WordPress/wporg-blocks repo on GH, and pull that into all the individual theme repos via composer, then sync it to meta.svn after merging.

The more repos we do ghat with, though, the more friction there'll be when making changes that affect all envs. That might be an acceptable tradeoff though.

How does that sound? Any better ideas?

something that takes an array of blocks you want to use

👍🏻

[coreymckrill]

but then where would we put it?

🤔 If we had a GH repo, we could sync it to dotorg.svn instead of meta.svn (so that the GH repo is the source of truth for the code, and we wouldn't get Trac tickets about it)

The more repos we do ghat with, though, the more friction there'll be when making changes that affect all envs.

Yeah, I could see that becoming a problem eventually. My inclination would be to cross that bridge when we come to it.

I guess one thing we could consider doing would be to have the repo be wporg-mu-plugins instead of specifically about blocks, with the idea that we'd eventually migrate all the other stuff there that we determine can be open sourced. Migrating wouldn't be a huge priority right now, though, because we wouldn't want it to slow down the News site project.

How does that sound?

[iandunn]

dotorg.svn instead of meta.svn

Doh, yes, 💯

cross that bridge when we come to it

👍🏻

have the repo be wporg-mu-plugins ... eventually migrate all the other stuff there ... wouldn't be a huge priority right now

Yeah, I like that idea 👍🏻

[iandunn]

Can you create that repo and add team permissions?

[coreymckrill]

✅ https://github.com/WordPress/wporg-mu-plugins

[iandunn]

replaced by WordPress/wporg-mu-plugins#4

[iandunn]

Yeah, I could see that becoming a problem eventually. My inclination would be to cross that bridge when we come to it.

Maybe one way to eventually deal with that would be to create a monorepo for wordpress.org code. Not all of meta, though, but only the stuff for the sites in the multisite instance.

But then, to avoid cluttering local envs with irrelevant code, each env could do a sparse checkout, and only pull the relevant subdirectories.

Although, at that point, it might be better to just have one env for the entire w.org multisite. Not all of meta still, though, just the w.org multisite.