Edit: Thanks for all the responses, I didn't expect we had so many webdevs here lol. To complete the brief, the first thing we'll need to do I think is upgrade the PHP which is on an EOL version. What we are looking for is someone who shows initiative, it's how we work at ProleWiki from the admins down to the newest editors. You'll be able and encouraged to come up with your own solutions, ours may of course not be the best we could get. Our keywords are scalability, maintenance, and optimization, always to better serve the readers.

We have tons of ideas for the future, but every time we find a developer, either they don't know PHP (I can't blame them) or they bail.

I'm looking for a PHP dev who wants to help out with ProleWiki. We have tons of cool ideas to really bring this show on the road, but nobody to put them into action.

Can't guarantee we can pay you (and if we can believe me it won't be a wage), but you get tons of perks such as being part of a cool, chill, growing community, a project bigger than any of us, and I can even write you a letter of recommendation I don't mind.

As we look towards the future and where ProleWiki can grow and better serve its readers, we come to the conclusion we need more tech. And for that we need at least one PHP dev.

ProleWiki runs on MediaWiki and a VPS. We're thinking of getting an S3 bucket as that seems more and more needed every day (it's just our processes make acquiring stuff a bit slow). One thing I would want to optimize for example is image delivery.

If you're interested hit me up.

  • nephs@lemmygrad.ml
    ·
    10 months ago

    On image delivery optimisation, what is the goal? Saving bandwidth depending on user agent? Or serving it from a different provider (like some form of s3 bucket?)

    Depending on the problem to be solved there's probably different approaches there.

    I can try to contribute with a some mediawiki extensions, somehow. Could be an interesting exercise. :)

    But also, are you guys using this? https://www.mediawiki.org/wiki/Manual:$wgUseImageResize It looks like images are currently served bigger than they should. Eg. at https://en.prolewiki.org/wiki/ProleWiki, the screenshot image is served at full size, despite being the size of a thumbnail on the page.

    Maybe there's simpler optimisation to be done before you need a "full" developer?

    • CriticalResist8@lemmygrad.ml
      ·
      10 months ago

      Thanks for the advice! The goal would be to improve page loading times (so saving bandwidth), and moving them to somewhere with more space because we use half the VPS storage space already. Give it another year or two and it'll be full, so a bucket is the next logical step.

      I didn't expect we'd have so many PHP devs here so I'm a bit booked up getting back to everyone but I'll write your name down and might contact you soon enough.

      • nephs@lemmygrad.ml
        ·
        10 months ago

        At your service. :)

        It's good to have the storage scaling and bandwidth concerns pointed out early, so then you can prioritise development properly, you people are amazing admins!

        If you decide to go aws route this looks like a simple solution: https://m.mediawiki.org/wiki/Extension:AWS there's also one for azure https://m.mediawiki.org/wiki/Extension:WindowsAzureStorage if you prefer another cloud overlord.

        I'd then configure thumbnailing, and make sure that syntax for all added images is correct. https://m.mediawiki.org/wiki/Help:Images#Size_and_frame

        This may still cause your server to read and resize images on each request, which is still not optimal, but maybe not the bottleneck.

        If after that you're still not happy with bandwidth costs, or performance, it may be worth it to configure thumbnailing to be uploaded and served from cloud provider.