"Wrong" Release process generates requirement to declare "wrong" parent theme about bootscore

[crftwrk]

Yes, of course. The child-theme is always tied to the folder name of the parent-theme. The child is there to change nothing in the parent theme.

The -main prefix is used to simplify handling for us and address the GitHub cloners as well. Changing this is not only affecting theme and child (breaking leads to v6 and we are nor ready for that yet), it will affect the entire repository with all plugins (they have an auto-updater). Changing folder isn't a small thing and will create a lot of trouble and confusion and I do not see any benefit here. However, what's wrong to keep -main prefix in releases?

FYI, I maintain a WP plugin that allows users to update from a remote Git Repo without the user of third party libraries, if it is something that interests you I can share the details in another topic.

Yes, of course! Plugins uses https://github.com/YahnisElsts/plugin-update-checker for auto updates. If we can skip this library, it would be great.

For the theme, it's still too early to integrate an auto-updater. Therefore, user should decide by himself if they want to update or not. There is also the option left to publish the theme in the WP repository at some point which includes auto updates as well.

[smileBeda]

I do not understand how the -main could help to differentiate from cloners? They can use -main as well (if what you mean is a "false" bootscore theme being published, I might misunderstand).

I am aware the child theme is dependant on the parent - that is not the concern. The concern really is that having the -main in a release is ... lets say just very uncommon (and can cause issues if you upload that very zip to WP Repo, for example, where they'll expect the actual slug to match)

However, of course, this is a minor issue compared what seems a larger consequence (did not know the plugins also point to -main theme file)

My suggestion would stand to try to "evade" this one now (before an online updater is available at which point it'll become impossible) but on the other hand I understand there's not much win (at least not on the surface) compared to the other things that can improve the theme (or plugins).

The main issue with -main really is that it comes from a branch name on GitHub, not from your product, and that (the repo) might change - the product name, less so. Thus (I think) this is why the bigger repos I have worked with (and from whom I copied practices and approaches, sometimes perhaps too blindly), try to avoid the branch suffix.

I am closing here, since I totally see your point - and I can always do that on my own in any theme built off the bootscore, if I need to

Thanks!

[smileBeda]

Update:

I also just recalled that WP offered a new plugin header directive for custom update server urls.
I am investigating that too, back when I wrote my plugin that did not yet exist.

Here the main question though is how far back your software supports WP. And, if it is even possible in themes. I believe not. So the custom code solution likely still is the way to go.

Can we have a ticket or so to bundle all the preparations and later work?

[crftwrk]

The -main suffix was not part of the theme before but this leads to issues with users who pressed the green Code button in each repo instead downloading a release. In this case the child does not work because theme folder was bootscore-main and child needed folder bootscore instead. After some user reports we decided to include -main suffix to each repos release.

In this post is explained why we changed bootscore to bootscore-main. This article is outdated and many things changed since this post was published. But it clears it up why keeping -main in the folder name is so much easier for us to handle the repos.

FYI, I maintain a WP plugin that allows users to update from a remote Git Repo without the user of third party libraries. if it is something that interests you I can share the details in another topic.

Yes, this is still very interesting. How does it work?

[smileBeda]

The updater works with GitHub API.
https://github.com/TukuToi/tukutoi-cp-directory-integration
Currently, this plugin is made solely for ClassicPress, so it would of course need to be refactored. All the MUST clauses in the description are likely inapplicable to this repo here since the logic would likely just be for this organisation and none other.
The API Key requirement (required once reaching limit of 60 requests per hour per questioner) also is likely not a requirement, since you do not have hundreds of repos.
As such, the integration could be made with significantly less code than the referenced plugin, and with a significantly nicer UX (as no GitHub API Key would ever be required).

Please let me know if you consider this, and feel free to open a new task and assign it to me with a description as of how you would like the integration (inside the theme/plugin or as a standalone "updater" plugin)
I am happy to start work on this.

Another solution I implemented is https://github.com/uhleloX/api, this one uses a more "professional" approach in the sense that you actually set up your own server where the releases are hosted, and deliver from there. This project is not a WP Project, but the same logic can work in WP too. This is neater in terms that if you ever decide to leave GitHub, or for whatever reason cannot store on GitHub anymore, you do not need to make changes to the update mech, and also can use the same server for other API handling (who knows maybe you want to substitute the template plugin with an online api instead, so the user can just click a button and download a template, for example)

[crftwrk]

Quickly installed https://github.com/TukuToi/tukutoi-cp-directory-integration and had rough view to it. If I understand it correct, this plugin manage plugins/themes from GitHub profile in WP backend on main site. If so, this is a good option and we can remove the plugin update checker. But it seems like a lot of work to adapt the plugin to this repo. Are you sure you want to invest the time into this?

[smileBeda]

Yes, in a nutshell that is pretty much what it does.

But it seems like a lot of work to adapt the plugin to this repo. Are you sure you want to invest the time into this?

I think less to adapt that plugin to this repo and more about just implementing a new one.

The reason is - that plugin, actually, you could already use for this repo!
You just would have to register your org/repo with the plugin and tada, it would start pulling updates. It would not even need code update - the user can register your repo on their own.
However, that plugin is NOT a WordPress plugin - it is a ClassicPress plugin. As such alone already it is not ok to use it as-is on a WP Install nor to build on it.

Unless you explicitly want to also support ClassicPress, what I would do is simply start anew with a way less complex plugin.
For your use case, I think:

• You do not need user-interaction (meaning the user does not have to specify the repos they want to sync with)
• You do not need integration with the ClassicPress Plugin repository
• You also do not need api key handling and the likes.

All you need is basically a small GitHub API interface, and an interface with the internal WP Update mechanism.
So, it should not be a too big amount of work, and yes, I would be willing to contribute this. I cannot make guarantees as of time, but I also will make sure to not take years for it 🤣

---

The question for me still is, do you want this as a standalone plugin, or as something you could integrate into your existing theme/plugin as a single file (as a class) and then require it somewhere in your code?
The latter approach is easier for the end user - they wont have to add another plugin - but is a bit more tricky (well, not that hard either) just so to avoid conflicts when several of the instances are loaded.

I think the include approach is probably neater than using a standalone plugin.

---

To conclude:

I think:

• one-file class to include into each of your software
• that class pulls from hardcoded repo (non-user editable, maximally maybe with a filter)
• the user has a seamless WP native update experience that basically does not differ from the other normal wp themes and plugins. I would not suggest a standalone update page like it is currently done on the existing plugin for ClassicPress (it has reasons it is done that way there, but makes no sense in a WP install)

[crftwrk]

Here the main question though is how far back your software supports WP.

bootScore is a WP project

So the custom code solution likely still is the way to go.

To be honest, I'm new to this. As mentioned, plugins uses https://github.com/YahnisElsts/plugin-update-checker so far. Theme not yet because we have to check for potential issues first before providing auto updates. We'll go the way you prefer.

Can we have a ticket or so to bundle all the preparations and later work?

Simply open a new issue, so we can track this in projects

[smileBeda]

bootScore is a WP project

I know (I think you meant to reply to the classic press detail?)
The question here was how many versions back you want to support wp.
Like… minimal required wp version.

In any case - ignore it as it’s not relevant anymore
I’ve the plugin updater class file ready and will share it either later or tomorrow. Then I’ll do the same for the theme.

I’ll let you know through a new ticket or even PR.