The extensions platform is out of experimental and ready for more heavy tests, and another round of feedback. You can read the official announcement here:
Login with your Blender-ID account to upload your extensions.
How to create extensions
This is more throughly explained in the documentation, but basically you will need a .zip file with your extension (e.g, an add-on) and a manifest file. This file will contain all the meta-data relative to this extension (replacing the need to add this in “bl_info”).
A bundle with all the 4.1 add-ons may be available to download, to smooth the transition from Blender 4.1 to 4.2.
Extensions installed this way don’t benefit from auto-update.
We are considering a global option in Blender to “Work offline” to prevent checking for updates. We still don’t have a clear design for this though.
Legacy Add-ons
Add-ons prior to 4.2 are considered legacy.
These add-ons can still be installed, and used, however they do not support the new auto-update system.
There is still a difference between Legacy add-ons (uses bl_info), and extensions installed from disk (uses manifest).
Add-ons can support both manifest and bl_info for backward compatibility.
Third-party stores + unique JSON
Commercial third-party stores can also be integrated with Blender to leverage auto-updates.
The recommended way of doing this is by creating a unique token to be used to deliver a JSON with the relevant extensions the user has access to. This will be implemented shortly.
If the server doesn’t support tokens, the recommended way is to provide unique URLs.
When submitting extension, there is a description field that supports markdown, but no preview available, I had to “unpack” browser dev tools and change markup on existing extension pages to see how heading would look like.
While initially surprised to find enabled add-ons / extensions were missing, after trying the online extension install have the following feedback…
Blender preferences > Extensions
Grouping extension types into categories, which are alphabetically sorted, would provide a cleaner interface and easier navigation.
An offline mode is something that needs to be in place from release, and users given a clear choice when opening the new version for the first time whether they want it offline by default. This is a new permission that connects to an outside source, and while most will probably have no issue with it (particularly those already using add-ons that poll websites), there is no guarantee everyone will grant that permission, so the option needs to be there as a matter of trust.
An option in preferences with sensible default and minimum intervals, and a manual check button or top level menu item for those who choose not to have auto-updates enabled seems fairly standard. I’ve been a desktop email client user since the late 90s, and they tend to have a “work offline” button tucked away in the status bar, so that’s another option.
Personally I’d prefer a separate extension installer program that looked similar to the current add-on install dialogue, but I know I will be in the tiniest of minorities on that, and it would be more effort for the devs to maintain than most other options, so not very likely.
As for the website, I’m not a fan of the grid layout with the large cards for each extension. I’m more of a compact list kind of person, I find them easier to navigate. I don’t know if different views (and option to change the number of items per page) could be implemented or would that be too much hassle? If it’s a no go, fair enough.
The extensions.blender.org access is not enabled by default. When you go to the extension preferences the first time there is a choice to enable it or not. And there is also an option to automatically check for updates or not.
The offline mode idea is about an option for Blender globally. So that would not only turn off internet access for extension repositories, but also other features like Blender ID or BlenderKit add-ons. The principle is already that all internet access is disabled by default, this would be about having a centralized control for it.
On a personal note, I’m not keen on the software I use connecting to the internet unless explicitly requested. Access to software repositories is all well and good, but I prefer to run these kinds of updates via the command-line.
One thing I found confusing about the Extensions UI in Blender with the default Blender http://extensions.blender.org/ repository is that add-ons and themes were mixed together in the same list. See example below.
I feel like splitting them into seperate lists, or adding some text, or a icon, to denote which is a theme and which is a add-on without having to expand the description would be useful.
I know there is the filter option, but subtle changes like that would be helpful.
The extension type in the Blender UI is not capitalised. It’s just something that bothers me.
I don’t know if this will work well, but maybe images could be shown when you expand a extension in the Blender UI? For example, I expand the Alien Pink extension and see the images from it’s extension page. This is particularly useful for themes.
Although, it could look out of place in the UI, and would increase data usage, which is not good for many people.
On the Blender extensions website, if I click on a add-on or theme, what does the “get theme” and “get add-on” buttons do? Or what is it supposed to do?
May I ask, are all add-ons and themes being uploaded to the extensions platform being manually reviewed before they become publicly visible?
Because if they aren’t then there are some risks associated with that which I’m a bit concerned about.
If they aren’t manually reviewed, then some people are going to break the guide lines.
Take for example the ND add-on. I would consider using the name “ND” breaking the “No surprises” rule found here: Terms of Service — Blender Extensions
But the ND example is relatively harmless. What if someone uploads a add-on with the same or similar name as a different add-on, but it contains nefarious code? From the Blender user interface, there’s no easy way to tell them apart. You have to go to the extensions platform website and check things like reviews and download counts to figure out which one is safe to download until it’s reported and removed. And some people aren’t going to do that.
Maybe review scores and download count could be shown in the Blender UI to help combat that issue?
Extensions are manually reviewed. Of course it’s possible we miss something, but that’s what “Report Abuse” button and reviews are for, so that users can help.
But I do share your concern that while it’s easy on website to see if add-on has bad reviews, you don’t see any of that from inside Blender. And because those add-ons appear in Blender, alongside trusted addons I think people will take them for legit.
I generally dislike the idea of EVERYTHING from the website appearing inside Blender. I have performance concerns, concern about reviews not showing, and also, I don’t think we should encourage users to enable add-ons without seeing previews and reading description, that’s just bad workflow.
I think by default only enabled extensions should appear, and new ones should be installed either by drag & drop, or by button like in 4.1. Uninstalled extensions should only appear if user explicitly states in preferences that they’re taking that risk (or never?)
But the problem is while this restriction will make sense for Blender extensions platform, and other commercial ones, I would want the opposite for private online repositories. If I have added repo where my company stores add-ons I want to see full list, including ones I haven’t installed. Most of them will not provide the functionality to drag & drop like extensions platform does, so search & enable will be used mainly.
I think what makes sense is if “Show Installed Only” was per-repository property, so that we could disable it by default for extensions platform, but enable it for custom ones
An idea that came to mind was having two extension repositories for the Blender extensions, similar to how there was “Add-ons official” and “Add-ons Community” previously. But I don’t know the full extent of which add-ons and themes are maintained by the Blender foundation, and if it’s worth the effort to set this system up just for that.
Shouldn’t all of this highly essential brainstorming and process cementation have been figured out before launching the extension platform? It’s so strange seeing developers on this thread and others musing about how to make the extensions platform work correctly and well, post-launch. Aren’t these things considered before launch? Isn’t that the point of having a pre-launch period at all?
If I pushed up a major breaking change into production without a thorough impact report and documented edge case testing at my job, I’d be fired. That’s just the norm for development. “Move fast and break things” isn’t employed at any corporate development environment because it doesn’t work. Why is it being used here?
These things have all been discussed long ago. In this case there is a contributor that was not involved in the extensions platform development asking questions now that the changes have become more concrete. Which is fair, we don’t expect everyone to read and think deeply about the consequence of all design docs.
It may be confusing, but there are many developers with various degrees of involvement. They’re not all representing the development team behind this project, just giving their opinion like any user can.
Although it is still in beta and may be in the planning stages, I hope that a robust filter will be applied to the extension web. While features like sorting by download count or popularity might be added later, I believe that sorting by time period is crucial. As time goes by, sorting by download count becomes less reliable. I think Sketchfab is a good reference for such filter sorting. Additionally, I hope there is a bookmarking feature. It would be very convenient if it could be synchronized with Blender.
I guess this will be mostly addressed by the plan to have a separate extensions and add-ons tab in the preferences.
I think this is mostly a practical reason. We can in principle implement this, along with description text rendering. But it may not be the best use of time. I think the Blender extensions tab is mainly for quickly installing things when you know what you want, and the website is for discovery.
This was broken yesterday for me, but it works now. Should be self explanatory when it works.
