[BUG]: Updating from 3.1.28 to 3.2.5 beta3 doesn't add the necessary repos to the table #1202
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: joomla/Component-Builder#1202
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What Happened?
When i updated from 3.1.28 to 3.2.5 beta3 it didn't populate the repositories table with the necessary repo's needed for joomla powers init function to work.
This will then throw an API error
Super Power repository at https://git.vdm.dev/api/v1/joomla/super-powers gave the following error!
Invalid response received from API.
Super Power repository at https://git.vdm.dev/api/v1/joomla/gitea gave the following error!
Invalid response received from API.
Super Power repository at https://git.vdm.dev/api/v1/joomla/openai gave the following error!
Invalid response received from API.
Would be nice if on update this would be populated so they work out of the box.
Steps to reproduce the Bug
Update fro m3.1.28 to 3.2.5 beta3 and try to update the joomla powers or powers area using the Init button.
Which Joomla version are you compiling in?
3.10.12
Which PHP version are you compiling in?
8.1
Which Joomla versions are you targeting?
3
Which PHP version are you targeting?
8.1
Which Web server is JCB running on?
apache
Which Relational Database is JCB running on?
mariadb 10.4
Which OS is JCB running on?
centos 7
Which JCB version are you using?
3.2.5 beta3
Where in JCB did this issue occur?
Powers(admin_views)
On which browsers did you encounter the issue?
Safari
Additional Comments
No response
[BUG]: Updating rrom 3.1.28 to 3.2.5 beta3 doesn't add the necessary repos to the tableto [BUG]: Updating from 3.1.28 to 3.2.5 beta3 doesn't add the necessary repos to the tableTom, the issue you’re experiencing stems from a situation we’ve encountered where our primary Git system has been overwhelmed by too many requests. As a result, we had to implement a robot verification system, which is unfortunately affecting the API as well.
To address this, we have decentralized all the core endpoints of JCB. Now, you can pull these endpoints from a diverse set of repositories. With the latest release (which is ready but not yet released, as I plan to finalize it next week), we are rolling out a feature that will automatically search for an available repository via an API we’ve established.
In the meantime, there is a workaround for this issue. You can check the status page for JCB, which is accessible via the status button on the git.vdm.dev website (located at the bottom of the page). Once there, scroll down to the JCB status section. You will find a list of alternative server and system endpoints where you can access the repositories. These endpoints are synchronized, so it doesn’t matter which one you use—they all work interchangeably.
To implement the workaround in JCB, go to the repository area and manually change the URL of the endpoint to one of the alternative options provided. This should resolve the problem and allow JCB to function as expected.
The larger context here is that our main repository is hosted on a dedicated LightSail server, which costs about $80/month. While it is a robust setup, JCB’s rapid growth has placed significant strain on this system, pushing it to its limits. Expanding this setup further is an option, but decentralization presents a more sustainable, long-term solution. It ensures that we don’t bear the full load on a single server, which is especially important as we continue to offer JCB as a free tool. By decentralizing, we distribute the load across the community, making the system more resilient.
I’ve personally moved multiple systems to this new decentralized network, and many of my colleagues and clients have done the same. So far, the transition has been smooth, and the decentralized endpoints are functioning well. If you’re encountering specific issues or are unsure how to resolve them, I hope this explanation provides the clarity you need. Similar concerns have been raised on GITI, and I’ve responded to them in a similar manner, offering the same solution.
In summary, while the growth of JCB has introduced some challenges, the steps we’ve taken to decentralize the repository network are designed to ensure stability and scalability in the long term. If further clarification is needed, we can certainly discuss this during the next JUG meeting.