Extiverse. Breaching the frontier in Flarum forum and community management
️
Is there a way to display plugins for all versions. It seems as per default it's filtered to the latest core release? Now it shows Extensions compatible with Flarum 0.1.0-beta.16 but there is no way to change that, or I am blind 
Makes it hard if you are not yet on the latest release and also to find plugins where help might be needed to upgrade them (eg. language packs, etc.)
rob006 our recommendation right now is this:
>=0.1.0-beta.16 <=0.1.0https://docs.flarum.org/extend/start.html#extension-packaging
[deleted]
luceos thanks for this. Just updated my extensions with the same constraints
rob006 That's true, but it's not a problem because the stable version will be tagged as 1.0.0, at which point we'll be recommending ^1.0.0.
askvortsov I don't get it. Unless you don't even plan to release 0.1.0, these recommendations will be harmful - extensions with such constraint will silently prevent updating to 0.1.1, which should be safe and recommended (assuming that there will be 0.1.1 release). If you actually don't plan to release 0.1.0, then simple ^0.1.0-beta.16 will be enough. So this recommendations looks either wrong or overcomplicated.
rob006 If you actually don't plan to release 0.1.0, then simple 0.1.0-beta.16 will be enough.
That is correct, we updated the recommendation the way we did mostly for consistency with previous interval-based versions. But yes, ^0.1.0-beta.16 would suffice. I don't know that it's necessary to amend / announce the change now, seeing that the stable release is coming soon, and the approach will be quite clear then.
askvortsov Well, that is surprising. I expected RC2 (as beta 17) first, so jumping straight to 1.0.0 is shocking 
. Especially that GitHub milestones still use pre-1.0.0 versions: https://github.com/flarum/core/milestones.
But back to my original question: what constraint should I use for my extension to both support beta 14 and be marked as compatible with beta 16 on Extiverse?
- Edited
Due to upgrading extiverse to Laravel 8 (and php 8) the images can no longer be generated for extensions that use a (complex) svg. These usually include language packs. My recommendation for now is to use a png or gif at a higher resolution. I'm occassionally working on this issue, but as imagick support/maintenance is pretty slow there's no fast solution. GD as an alternative has no support for reading svg sadly.
On another note I added Open Graph images (and meta data) to extension pages, resulting in these kind of images when shared on channels that support open graph images:
luceos Is there any reason to do SVG to PNG conversion using PHP? AFAIK there is a plenty of console tools for that, and even online services with API and free tier. Old PHP implementation never worked well (like Polish flag in my language pack is literally two rectangles and it does not work on extiverse since the begging) so switching to different approach may be easier and more reliable than waiting for imagick.
rob006 yeah I know, I was playing around with a package from npm, but that didn't result in anything better. What I'm now considering is extracting the logic I had from my app codebase and pushing that into a docker image with PHP 7.4 and imagick, that one worked well. But if you have any recommendations for API's that work too, please let me know; although I probably have a much higher volume than you do 
luceos https://cloudconvert.com/pricing has 25 conversions per day in free tier. It is not a lot, but there is like 1-2 new extensions per day, so it should be enough to handle new extensions and refresh icon for old extensions if icon was changed (should be pretty rare). I hadn't used their API, but I tested their web tool and it converts my icon correctly.
So I just sat down for this issue and resolved it. Moved logic out of the extiverse.com codebase so that it could be ran as a separate docker image on a specific php version with a working imagick version. Firing these svg icon (and fa icon) conversion tasks towards docker from queue jobs has been a very reliable and scalable solution so far.
- Edited
There are some issues with extiverse, I'm looking into it.
Update; after close to 10 hours working on this deep into the night I zeroed down on the issue. The API is functional again, but the site temporarily is no longer filtering on the latest Flarum version. I will need to do further investigation why exactly that filter is causing timeouts.
Update; fixed the issue, seemed versions and their compatibilities would be stored on every sync causing the table to fill up unnecessary and creating very long running queries when queried. I flushed the table and fixed the duplication issue.
Compatibility is detected based on constraints from last release/tag? Or maybe this is detected based on state from default branch? I noticed that https://extiverse.com/extension/kilowhat/flarum-ext-wordpress suddenly was marked as incompatible, but there were no new releases of this extension in the meantime (and no new releases of Flarum).
rob006 that's curious. There are no additional commits on dev-master compared to the latest release. Requirement is still >=0.1.0-beta.16 <0.1.0-beta.17 in composer.json
Hello 
to my extiverse followers,
I need your opinion on the following. For months - off and on - I have been working on a crowdfunding feature for extiverse, allowing people to back new feature requests, compatibility patches and bug fixes. It's a feature that needs to be thought out to prevent disappointment from the parties involved.
To get a better idea what would work I would like to bounce the following two ideas off of you.
Crowdfunding A
As a user you can create a request to get an existing extension patched for a new flarum version, fix a bug or - also for requesting a new extension - request a feature. Once you, as author, put a pledge on the request it will be published for others to also back. Once a request gains enough pledges verified developers will be able to pick up the request with the requirement to resolve it within a set time.
Once a request has been resolved by the developer, the backers can vote on the quality of the produced results. Or alternatively I am considering some kind of internal QA process.
The benefits of this approach that users and developers have is that they have a lot of flexibility on what to back and what requests to pick up.
Crowdfunding B
The alternative is based on how Wemod works. Users become FOSS donators, paying a monthly fixed fee that becomes part of a general budget. Donators are allowed to create and upvote extension requests (patch, bug fix and feature implementation).
Based on these upvotes developers can pick up one of the highest upvoted requests. Developers then keep track of their time and get compensated exactly for that amount from the budget. Other developers or a QA team will always review fulfilled tasks above a certain threshold.
The benefit of this approach is that the recurring payments allow developers to understand exactly what their gain can be in the long run. It might even allow me to hire developers to tackle the workload. It's also easier for user in payments, being a subscription model.
Great feature! My vote is for A
I also like Version A - there are so many subscriptions (non-flarum related) ongoing I think it will be hard to "sell it".
I vote A
I also vote for A
I somehow think B is more manageable though A looks better for individual contributors. I vote for B.
Can both approaches be implemented?
almalino I think too many options at once might be confusing and dilute potential impact.
I think I'll stick to option A for now. I've also started with that implementation already and the consensus seems to point at that one too. I'll try to push forward with this feature during my couple of days off this week.
I really like this idea, it's a way to formalise the crowdfunding of extensions, as right now it's quite complicated to give visibility to an idea and get it off the ground. I agree, option A is probably the best way to start and see how it works.
@luceos i'm trying to validate my account on extiverse, but when i click on the validation email, it says "invalid signatures"
When viewed on mobile devices there are some styling issues making content unavailable to view. See screenshot:
I've implemented a new design, which is much darker. This comes with an upgrade of tailwind and laravel mix. There are still a ton of issues while I patch things up the coming days. Feel free to report any layout or major styling issues you find.
Justoverclock Can you ping me on discord? I'm on holiday right now so I'll need to check when behind a PC.
GreXXL that's an older issue. I'm going over some rudimentary styling changes this week.
Is there a chance to add to API actual constraint for flarum/core used by extension, instead of simple compatible-with-latest-flarum flag? I have different rules for detecting compatible extensions, and it is really hard to guess how exactly treat some premium extensions marked as incompatible at Extiverse.
I am considering building an Extiverse extension that:
- shows one button in the dashboard stating "up to date" or "outdated"
- has a new tab where you can see all your current extensions and whether they have updates
- the ability to use a cronjob to send email notifications to admins when new updates
Would this appeal to you?
luceos release as extiverse/mercury
Extiverse no longer syncs extensions each hour from packagist. Their endpoint was cached and has been marked deprecated. So I decided to switch over to their endpoint that allows reading just changes. As a consequence Extiverse now sees changes to extensions within 10 minutes. A full sync happens each night to make sure nothing is missing.
Premium extensions are an exception as they still are synced only hourly. I don't want to push too much weight on the VCS providers by reducing that interval.
If you encounter any issues with missing data or delayed updates, please let me know.
Am I the only one who is constantly being pulled out? For the last few days I have been getting logged out after a couple of hours even if I log in again with the remember tick.