Essay:ProleWiki news logs/28 February 2024: Difference between revisions
More languages
More actions
(Created page with "== PHP Devs == We have brought two PHP developers to ProleWiki over the course of February, which has also renewed interest in our developer editors. Their help was very much needed at this stage to breach through what MediaWiki and third-party extensions can do for us, and really customize ProleWiki into something that fits our specific needs. To that end, this success in bringing in developers specifically for this purpose represents a bigger So far we have started...") Tag: Visual edit |
General-KJ (talk | contribs) No edit summary |
||
(One intermediate revision by one other user not shown) | |||
Line 2: | Line 2: | ||
We have brought two PHP developers to ProleWiki over the course of February, which has also renewed interest in our developer editors. | We have brought two PHP developers to ProleWiki over the course of February, which has also renewed interest in our developer editors. | ||
Their help was very much needed at this stage to breach through what MediaWiki and third-party extensions can do for us, and really customize ProleWiki into something that fits our specific needs. To that end, this success in bringing in developers specifically for this purpose represents | Their help was very much needed at this stage to breach through what MediaWiki and third-party extensions can do for us, and really customize ProleWiki into something that fits our specific needs. To that end, this success in bringing in developers specifically for this purpose represents the beginning of many things to come. | ||
So far we have started a codeberg repo for version control, which will let them work on the code without risk of breaking the website and needing access to the server. We have lots of ideas that they could help on, which will be developed in later news logs when they are achieved. | So far we have started a codeberg repo for version control, which will let them work on the code without risk of breaking the website and needing access to the server. We have lots of ideas that they could help on, which will be developed in later news logs when they are achieved. | ||
Line 16: | Line 16: | ||
We've been preparing the config files as well for upload on codeberg, as some files needed to be cleaned up or protected from being shared as they contain sensitive information. We also cleaned up user permissions as best we could, since we needed to make a new 'tech staff' role and we previously made a 'library editor' role that could normally only edit the library but, we've found that this wasn't the case. | We've been preparing the config files as well for upload on codeberg, as some files needed to be cleaned up or protected from being shared as they contain sensitive information. We also cleaned up user permissions as best we could, since we needed to make a new 'tech staff' role and we previously made a 'library editor' role that could normally only edit the library but, we've found that this wasn't the case. | ||
The way perms now work is all namespaces are manually protected from edits by anyone. Then, we give the 'user' role (the one every approved editor gets) permissions into the protected namespaces, such as main, library, essays, etc. For roles where we want to limit namespace permissions | The way perms now work is all namespaces are manually protected from edits by anyone. Then, we give the 'user' role (the one every approved editor gets) permissions into the protected namespaces, such as main, library, essays, etc. For roles where we want to limit namespace permissions. Anon users (asterisk* group) just don't have any perms. With this new system, even if you have the 'edit' perm set to true, you can't edit anything until individual namespaces are "unprotected" for your role. | ||
It's not super pretty in the files and it's a chore to set up, but at least it works properly and we won't get any surprises in the future. It also allows us finer control over which namespaces which roles can edit, if we need more of these roles in the future. | It's not super pretty in the files and it's a chore to set up, but at least it works properly and we won't get any surprises in the future. It also allows us finer control over which namespaces which roles can edit, if we need more of these roles in the future. | ||
== Partnerships with other orgs and projects == | == Partnerships with other orgs and projects == | ||
We are starting to slowly partner with other orgs and projects, unofficially and as a gesture of good will for the time being -- ProleWiki remains an independent project. We have invited editors from [https://unity-struggle-unity.org Unity Struggle Unity] on our server and vice versa to keep a line of contact open and hopefully learn from each other, and see where it develops from there. We have also had content creators and members or cadres | We are starting to slowly partner with other orgs and projects, unofficially and as a gesture of good will for the time being -- ProleWiki remains an independent project. We have invited editors from [https://unity-struggle-unity.org Unity Struggle Unity] on our server and vice versa to keep a line of contact open and hopefully learn from each other, and see where it develops from there. We have also had content creators and members or cadres from some parties for a while now, so developing some sort of structure in this direction will help formalize their presence and hopefully build something meaningful out of it. | ||
[[Category:ProleWiki news (essays)]] |
Latest revision as of 20:06, 14 November 2024
PHP Devs
We have brought two PHP developers to ProleWiki over the course of February, which has also renewed interest in our developer editors.
Their help was very much needed at this stage to breach through what MediaWiki and third-party extensions can do for us, and really customize ProleWiki into something that fits our specific needs. To that end, this success in bringing in developers specifically for this purpose represents the beginning of many things to come.
So far we have started a codeberg repo for version control, which will let them work on the code without risk of breaking the website and needing access to the server. We have lots of ideas that they could help on, which will be developed in later news logs when they are achieved.
A new role was created for them, and along with the repo, we could imagine giving this access to more than just editors or even communists. Anyone could potentially contribute on the repo (which is private at this time) once it's properly set up through a 'confirmation' . We have to think about it more of course, but it's a possibility. This is pretty interesting for the project evolution, where we don't necessarily have to depend on finding the "unicorn" (a long-time Marxist-Leninist that has a perfect understanding of our needs and the skills to solve them).
Download pages as pdfs
At the same time, we deployed the Collection extension to make our pages downloadable as books. There's still a few issues (for example the link to create a book only appears on the homepage megamenu), but the mechanism works great. Somehow I remembered Collection not working at all and not being updated for our MediaWiki version, but checking it up again everything works great. We had to do some maintenance in the extension files though (for example the provider says the PDF rendered has been disabled but it works just fine. We also had to fix a bug that was pushed to the repo, but not to our version).
Now that we have developers we can also start looking at improving and fixing this extension, seeing that it seems kind of unstable (on the level of the vision the maintainers have; the extension works just fine). But being able to collect several pages and download them as one file is incredible, it's a great extension otherwise and also a huge step for accessibility.
Backend cleaning
We've been preparing the config files as well for upload on codeberg, as some files needed to be cleaned up or protected from being shared as they contain sensitive information. We also cleaned up user permissions as best we could, since we needed to make a new 'tech staff' role and we previously made a 'library editor' role that could normally only edit the library but, we've found that this wasn't the case.
The way perms now work is all namespaces are manually protected from edits by anyone. Then, we give the 'user' role (the one every approved editor gets) permissions into the protected namespaces, such as main, library, essays, etc. For roles where we want to limit namespace permissions. Anon users (asterisk* group) just don't have any perms. With this new system, even if you have the 'edit' perm set to true, you can't edit anything until individual namespaces are "unprotected" for your role.
It's not super pretty in the files and it's a chore to set up, but at least it works properly and we won't get any surprises in the future. It also allows us finer control over which namespaces which roles can edit, if we need more of these roles in the future.
Partnerships with other orgs and projects
We are starting to slowly partner with other orgs and projects, unofficially and as a gesture of good will for the time being -- ProleWiki remains an independent project. We have invited editors from Unity Struggle Unity on our server and vice versa to keep a line of contact open and hopefully learn from each other, and see where it develops from there. We have also had content creators and members or cadres from some parties for a while now, so developing some sort of structure in this direction will help formalize their presence and hopefully build something meaningful out of it.