🔥Floxum, managed hosting & extension marketplace

ernestdefoe

Capybara well for me for right now is to have them all with a green check mark. Last time I checked they all did.

Capybara

ernestdefoe Great! That means you did a good job. I still have one extension showing up in yellow, but I’ll fix that soon

ernestdefoe

Capybara now when I have the time I’m going to make sure all of my extensions are 90/100. Hopefully without breaking something else. My goal was all green check marks which again last time I looked they all were.

luceos

Floxum is currently not showing any compatible extensions with RC.2. This is caused by the code not seeing the need to do a full sync. As this has been an issue that has been going on for a long time, I'm looking at a sustainable solution to this issue.

This issue will be fixed within the next two hours.

Thank you for your patience.

huseyinfiliz

luceos I haven't encountered an issue like this with the Flarum.org extension marketplace I'm currently working on. In fact, when you mentioned a Packagist-related update issue a few days ago, I didn't experience any problems either.

If it's not something that needs to remain confidential, could you briefly explain how you determine which Flarum version an extension is compatible with? Perhaps the method I'm using is more effective, and I could explain how I've designed it. It automatically tracks Flarum updates and immediately processes compatibility information for older extensions.

At the moment, Flarum.org stores extension compatibility data like this:

{"2.0.0-rc.2":true,"2.0.0-rc.1":true,"2.0.0-beta.8":true,"2.0.0-beta.7":true,"2.0.0-beta.6":true,"2.0.0-beta.5":true,"2.0.0-beta.4":true,"2.0.0-beta.3":true,"2.0.0-beta.2":true,"2.0.0-beta.1":true,"1.8.16":true,"1.8.15":true,"1.8.14":true,"1.8.13":true,"1.8.12":true,"1.8.11":true,"1.8.10":true,"1.8.9":true,"1.8.8":true,"1.8.7":true,"1.8.6":true,"1.8.5":true,"1.8.4":true,"1.8.3":true,"1.8.2":true,"1.8.1":true,"1.8.0":true,"1.7.2":true,"1.7.1":true,"1.7.0":true,"1.6.3":true,"1.6.2":true,"1.6.1":true,"1.6.0":true,"1.5.0":true,"1.4.1":true,"1.4.0":true,"1.3.1":true,"1.3.0":true,"1.2.1":true,"1.2.0":true,"1.1.1":true,"1.1.0":true,"1.0.4":true,"1.0.3":true,"1.0.2":true,"1.0.1":true,"1.0.0":true,"0.1.0-beta.16":false,"0.1.0-beta.15":false,"0.1.0-beta.14.1":false,"0.1.0-beta.14":false,"0.1.0-beta.13":false,"0.1.0-beta.12":false,"0.1.0-beta.11.1":false,"0.1.0-beta.11":false,"0.1.0-beta.10":false,"0.1.0-beta.9":false,"0.1.0-beta.8.2":false,"0.1.0-beta.8.1":false,"0.1.0-beta.8":false,"0.1.0-beta.7.2":false,"0.1.0-beta.7.1":false,"0.1.0-beta.7":false,"0.1.0-beta.6":false,"0.1.0-beta.5":false,"0.1.0-beta.4":false,"0.1.0-beta.3":false,"0.1.0-beta.2":false,"0.1.0-beta":false}

luceos

huseyinfiliz I haven't encountered an issue like this with the Flarum.org extension marketplace I'm currently working on. In fact, when you mentioned a Packagist-related update issue a few days ago, I didn't experience any problems either.

The issue with the stale packagist data was confirmed by the composer team in fact, I mistakenly didn't use the p2 endpoint as per their documentation. I had been made aware of this endpoint a few years ago, but decided against using it because it cached with a delay back then. Something must have recently changed that the endpoint I was using is now being cached more vigorously.

As for the compatibility issue, the problem is that when a new version is released the scheduled task that currently only syncs changes from composer (using their dedicated endpoint) is supposed to disable the flag to only run changes and do a full sync instead. Somewhere in this code, and using redis cache flags, it's not properly identifying the need to do a full sync. Not a big problem, but I've attempted to fix this in the past with less brain capabilities 🙈 than today.

huseyinfiliz

luceos Don't you pull Flarum versions from Packagist?

luceos

There we go, 2118 open source extensions have synced, premium extensions as well.

huseyinfiliz Don't you pull Flarum versions from Packagist?

I use composer and packagist interchangeably, they use the same API, it's also the same team with Jordi and Nils.

luceos

One thing that is interesting though is that composer added a way for repositories to introduce dependency policies (https://blog.packagist.com/composer-2-10-release/).

This would allow the Floxum repository to report audit information back to any composer command when executed, the claude code reviews could then be used on a per extension version basis to prevent or warn about installation of risky extension versions.

Is this something people would be interested in?

Capybara

luceos The Composer warnings sound useful, especially for security issues. Auditing Flarum 1.x and 2.x versions separately could help, but it might also add unnecessary overhead for Floxum. Most users upgrade to the latest version anyway

@ernestdefoe

luceos

Was actually working on getting 2.x on our hosting platform, but made a small modification to the extension detail page.

It now shows all versions as a table at the end of the page with their compatibility against 1.x and 2.x latest version plus the code review verdict. This table will also allow maintainers to initiate reviews for versions independently.

I will soon add a way to view the actual per version code review.

« Previous Page