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.
(Don't know php and I'm honestly biting more than I can chew with what I have going on currently)
Is the project open source? Are the ideas complex to implement apart from the things you have mentioned? Just curious, I unfortunately don't know any comrade who knows php
Not everything is open source. MediaWiki is, the theme we use is, but the content on ProleWiki or the stuff ProleWiki makes is not always, for example our self-made templates (which are like functions that you can use on wiki pages to display content). We've made some contributions to our own git when we've had to change some plugins code (the plugins are open source and so are our contributions there) but the ideas we would be developing would likely not be open source just yet.
Complexity depends on how familiar with MediaWiki one is, but I think the main difficulty will be resource management so as not to overwhelm the server.
I see. I mentioned it more to know if I could look at the code you wanted to expand on sometime.
Oh yes, Github (or Gitlab, or Codeberg, or whatever) would be really great. Working together, as we always do!
I know php and I’ve done a few Wordpress projects before. I’m a little busy right now but I can spare about an hour a week helping out.
By the time you need a PHP dev to run a MediaWiki instance you should probably ditch it for something with a more attractive language. It will be less work.
I strongly disagree with this one.
20 years in the industry, and php is still the ak47 of web. Runs anywhere, ridiculously reliable for most projects, no extra frontend shenanigans, out of the box server side rendering.
I don't know about mediawiki specifically, but laravel projects are generally acceptable from a modern development perspective, even though setting up the dev environment can be more tricky than an out of the box vscode/ts/react setup.
ditch it for something with a more attractive language
Yea... just one problem: what?
I would simply write a superior wiki platform than Wikipedia’s from scratch in Rust /s
Just casually duplicate this labor rq. Techbros really creating jobs for each other.
Basically anything else will be easier if you need to write custom back end things. XWiki or wikijs, even.
ain't S3 amazon's? if that is the case wouldn't be better to host it on chinese cloud service?
I have worked with "plain" PHP before (no Composer) — and HTML, CSS, JS, of course. I am by no means a professional programmer and I have little time lately (being a university student is not easy), but I hope I can still help as a volunteer in any small way. :)
That said, MediaWiki has an enormous codebase. I've never been really fond of this bloated piece of software that runs Wikimedia websites... but I can understand why the choice was made.
In your case I think I have something even better to offer you 😁 you can join ProleWiki and, as a student, figure out where you could help improve something. The keywords are scalability, maintenance, and optimization (optimization being a very large term). This would let you work on smaller projects that are also specific to MediaWiki at first, and learn the CMS.
I say that because we have a webdev student already, albeit with time permitting. And I can see most of the time he's very, very careful about making any changes (and I am too, since I'm not a web developer either). We also don't have a dev environment due to storage space restrictions, so everything is pushed straight to the live site lol. Tell me if you're interested and I'll send you the discord invite.
I'm not a webdev student, I should have made it clear that my studies are related to IT. I just wanted to help out in some way (not necessarily by programming). Also, I don't use Discord, sorry.
Maybe I could help out as an editor to the English version or I could help create a Greek edition (I'm a native speaker 😉)?
You can definitely request an account and I know one of our Greek editors was looking for other people to start an instance with! We're in the process of bridging the matrix server with some channels on the Discord but it's not 100% set up yet (currently only goes one way from Discord -> Matrix).
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?
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.
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.
Its seems pretty interesting. Now day MediaWiki is one of the largest codebases in PHP out there. But Wikimedia has excellent resources, somewhat extensive, but very good, from the lowest level sections (database, backend) to the style (css), plugins and frontend, including the scripts (lua). Although as @CriticalResist8@lemmygrad.ml comments that much is done in a very artisanal way, I think more than anything that the correct organization of the main dev, including admins and contributors, a lot of progress can be made with the limited resources available.
