Extiverse. Breaching the frontier in Flarum forum and community management

Darkle

luceos Ok I understand, I really didn't express well what I meant by "sell" in the extended plan it was a mistake but now I understand it correctly, sorry for my English. The only doubt I have is that in the case of extensions without extended plan that only offer the standard one, that I want to use in forums with profit (with low income or practically null, but offering the options) what could I do about it, contact the developer? or in this case would it be allowed to use the standard?

luceos

Darkle it's best to contact the developer in that situation 👍️

GreXXL

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.)

luceos

GreXXL use extiverse directly:

https://extiverse.com/?filter[flarum-version]=0.1.0-beta.4

That filter is not publicly shared as hardly anyone needs it. Make sure to append that filter segment when you use the interface.

rob006

luceos How this flarum-version filter (and in general default filter) works? I mean if I have ^0.1.0-beta.14 as constraint in my extension, why it is not showing for 0.1.0-beta.16?

luceos

rob006 because beta 16 is marked as backward incompatible. You have to explicitly include an upper limit. Because if I don't the ancient extensions created during beta 1/2/3 will be compatible with beta 16 too.

rob006

luceos So if I change constraint to >=0.1.0-beta.14 <0.1.0-beta.17, it will show as compatible?

luceos

rob006 our recommendation right now is this:

>=0.1.0-beta.16 <=0.1.0

https://docs.flarum.org/extend/start.html#extension-packaging

rob006

luceos Are you sure that these recommendations are correct? >=0.1.0-beta.16 <=0.1.0 would be compatible with 0.1.0 but not with 0.1.1 (patch release, by definition it should not break anything).

[deleted]

luceos thanks for this. Just updated my extensions with the same constraints

askvortsov

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.

rob006

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.

askvortsov

rob006 If you actually don't plan to release 0.1.0, then simple ⁰.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.

rob006

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?

luceos

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:

rob006

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.

luceos

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 😉

rob006

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.

luceos

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.

luceos

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.

« Previous Page Next Page »