|
Re^5: Ideas for PerlMonks 2.0
by jdporter (Paladin) on Dec 06, 2024 at 22:41 UTC
|
We should, at some point, enumerate the ways in which we want the new system (PM2) to be modern, to be "breaking".
One way, I feel strongly, is that writeup syntax should be Markdown, or perhaps better, MediaWiki#Markup.
With that given, then:
make the following things work from day one:
- Import all existing posts and User accounts from PM and make them render as correctly as possible.
- Node-IDs will continue to work as they are now and with the IDs unchanged for existing posts.
I disagree with these. The new system should start empty of content. However, it should provide an easy way to bring in PM content (posts, comments) via transclusion.
We'd be transcluding the rendered html, not the raw node source, so we wouldn't have to worry about the weird PM-specific HTML variant.
With regard to importing the user accounts: That might be a nice thing, at some point, but I would say:
- It doesn't need to have been done by Day 1. We can bring them in a little later. Could even have a way of auto-importing jdporter from here when that user registers there — optionally.
- We certainly wouldn't import all extant PM users. Maybe just those which have been active here in the last year, or something.
- Make sure existing external links to PM (including to specific posts) continue to work as normal.
Do you mean a link in PM2 node source like [id://674668] would make an external link from there to here? I address that above.
Of course, the other side of "continue to work" is that the referenced resource on PM continues to exist and be reachable.
That is something that would be out of PM2's hands. But maybe you could build in the smarts to redirect to the Wayback Machine
automatically when PM inevitably evaporates.
There has been lots and lots of discussion, over the years, of what a replacement system / PerlMonks 2.0 would, could, or should look like.
Unfortunately, it isn't particularly easy to find. Please go looking, and I will do the same.
Thank you for the good work, and thank you for volunteering!
Today's latest and greatest software contains tomorrow's zero day exploits .
| [reply]
[d/l]
[select] |
|
|
I'd much rather see a drop-down that lets the user select the format they were writing, and "Classic PM" would be one of the options, along with Markdown, and maybe WSYIWYG. The default would come from user settings. The database table would consist of "ContentType" and "Content", and ContentType would select the rendering module which converts it to HTML, then you cache that in a separate layer. This is how many content systems work, including Drupal.
This way you have the option to go back and re-render everything to handle new ideas for site design that depend on changes to the tags, and you leave everyone with the ability to continue to edit their posts from before the cutover.
The entirety of the rendering for old PM format should be bundled up into a module and given unit tests. It's more effort, but I strongly feel this is the "right way" to handle it.
It also lets you iterate on Markdown rendering, later. You could internally have formats like "text/markdown-2024" and "text/markdown-2027" and show them to the user as simply "Markdown" while using the specific type stored in the table to keep rendering the content with the same renderer as it was written, so that new Markdown implementations don't break historic rendering.
| [reply] |
|
|
I'd much rather see a drop-down that lets the user select the format they were writing, and "Classic PM" would be one of the options, along with Markdown, and maybe WSYIWYG. The default would come from user settings. The database table would consist of "ContentType" and "Content", and ContentType would select the rendering module which converts it to HTML,
(or anything else, like XML)
I strongly feel this is the "right way" to handle it.
I had that in mind, too, but lacked the time to write it down. Having a "Classic PM" renderer would allow copying all content nodes from the existing PerlMonks to PM 2.0 in source form, no conversion needed, no complex interaction between PM 1.0 servers and PM 2.0 servers needed. Once all data is migrated to PM 2.0, PM 1.0 can be shut down.
Looking at very old nodes, it might perhaps be useful to have an "Ancient PM" renderer in addition to the "Classic PM" renderer, because obviously the PM approved HTML subset has changed over time. But having just the "Classic PM" renderer would already be a great migration helper.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
|
|
... a drop-down that lets the user select the format they were writing, and "Classic PM" would be one of the options, along with Markdown...
The database table would consist of "ContentType" and "Content", and ContentType would select the rendering module which converts it to HTML, then you cache that in a separate layer.
In fact, I started work on implementing exactly this here, a while ago. See document2 devdoclet. (If you can't access that, see Markdown is now supported for comments, experimentally)
| [reply] |
|
|
The new system should start empty of content.
I disagree with you on that one. Sorry.
I really like the idea that PM is a continuous thing for over two decades. I'd rather spend the time to find a way to convert existing nodes as well as possible to the new markup.
This would also help with search functions and linking to old posts. Having the whole history of PM posts, with all functionality is one of the things that makes PM a great resource.
Also, the exact type of markup shouldn't be a big issue either way for most users, my focus would be on supporting a WYSIWYG editor by default.
Same goes with the existing user accounts, we should import them as is, possibly deactivating older, unused accounts, e.g. disable login but have a simple way of re-enabling on demand. This way, the usernames stay reserved for the people who come back to PM after a few years. It also preserves the history of the site. This includes monks (and their posts) who have passed away - i can't, in good conscience, just drop all that stuff and relegate it to some hard-to-find archive when we have a relatively easy way to preserve that stuff in the live system.
Do you mean a link in PM2 node source like Markup in the Monastery would make an external link from there to here?
No, i mean links from external sites to PerlMonks. Cool URIs don't change
I think this is something that is easily achieveable in my framework with a few hours of work, especially if we do import all the old posts.
| [reply] |
|
|
This would also help with search functions and linking to old posts. Having the whole history of PM posts, with all functionality is one of the things that makes PM a great resource.
I believe it should be possible — and in fact far easier — to achieve the desired functionality without copying the nodes to the new system.
I.e. we can make nodes on the old system (here) appear in the new system. We can support replying to them, and all that.
We can create the APIs here necessary to support such integration. We can make the two systems work together as seamlessly as we want.
Trying to copy the nodebase — any subset of it — would essentially infect the new system with bad design decisions baked into this system.
| [reply] |
|
|
|
|
|
|
|
|
I have a few suggestions. For example, when I search the site, there should be a switch that allows me to search for part of a word or whole words only. Right now if I type in something such as "webp" if I want to look for conversation on webp processing, then it will list a bunch of results containing "webperl" and "webpage" which is not what I want. I saw no way to tell the search engine to search for whole words only.
Another suggestion: Allow people to use a predefined CSS design instead of writing your own. It's nice that some people say, "hey, you can use your own design. You can configure the site's look and feel in any shape or form," but imagine if someone does not want to spend a whole afternoon customizing his experience on PerlMonks. Let's say I want to have a cool configuation in 3 seconds. There should be a drop-down menu that offers me to choose between site designs and pick one instead of me having to do all the coding. What if I don't want to do the coding?
The site should have the ability to upload a file like a zip file containing a bigger program than just a code snippet. And the website should allow people to post pictures if they want to.
Have the ability to upload a zip file into each person's profile. For example, each person would get maybe a 100MB storage space to upload a ZIP file which might contain modules or work that the person wants to share. This again, could be searchable. You might say, "Well, there is CPAN. That's precisely what you're describing. Upload your files and it's searchable." Yes, but it's not so simple as just upload your files. There's a bunch of requirements on CPAN. Module have to be a certain way. You can't just upload any random files to CPAN.
| [reply] |
|
|
"Allow people to use a predefined CSS design instead of writing your own."
Several of your historical responses have informed you that css is customisable, in terms of a single pre defined change see Display Settings -> 'Theme container'.
"And the website should allow people to post pictures if they want to."
People can link to an image should they wish, outside of home node images I see no benefit to the burden of hosting them here. It'd add more janitorial work.
"Have the ability to upload a zip file into each person's profile."
This creates more problem and janitorial headaches than it solves problems, github (along with their gists), gitlab (along with their snippets) and a multitude of other sites and services provide this. People already do this and just link to the information. It's a wheel that no one need reinvent here.
| [reply] |
|
|
Yes, but it's not so simple as just upload your files. There's a bunch of requirements on CPAN. Module have to be a certain way. You can't just upload any random files to CPAN.
There are plenty of other sites which can act as filestores such as gitlab, github, google drive or even your own neocities site. There's no reason not to use one of those instead.
And the website should allow people to post pictures if they want to.
It already does. And you know this.
| [reply] |
|
|
when I search the site, there should be a switch that allows me to search for part of a word...
There is no doubt that our search could be more capable. But how about, instead of getting into
the details here, we simply say that the new site should have powerful, modern search capabilities.
We'll probably use some existing, off-the-shelf technology (Lucene, maybe?) for searching.
And we are not going to re-invent Google. You know you can already
use Google to search PerlMonks, right?
The site should have the ability to upload a file like a zip file containing a bigger program than just a code snippet.
Have the ability to upload a zip file into each person's profile....
Absolutely not.
That being said, we could probably have better "integration" with external filedump sites such as github and pastebin.
the website should allow people to post pictures if they want to
Unlike some others here, I am not fundamentally opposed to this. We'd want to be sure to limit the capability, e.g. max size, max dimensions, max number of images uploaded, etc.
And users (readers) should be able to choose how "embedded" images get rendered — either in-line or as links they can click on (rather like how we treat spoilers).
Today's latest and greatest software contains tomorrow's zero day exploits .
| [reply] |
|
|
|
|
|
|
|
|
|
|
| [reply]
[d/l] |
|
|
For example, when I search the site, there should be a switch that allows me to search for part of a word or whole words only.
If we go for my PageCamel framework, there are two ways of achieving this:
- a SuperSearch like feature with all the options
- a user setting that defines the behavior of the default search boxes
| [reply] |
Re^5: Ideas for PerlMonks 2.0
by hippo (Archbishop) on Dec 06, 2024 at 14:24 UTC
|
Utilize existing PageCamel features like continously scrolling lists instead of paginated views for a more modern feeling and a better mobile experience.
I like pagination. It is so much more user-friendly than the infinite-scroll horror. If you (or anyone else) is going to implement infinite-scroll here, please ensure that it is optional and can be switched off on a per-user basis.
| [reply] |
|
|
| [reply] |
|
|
As long as the scrolling is not infinite, I prefer it very much over pagination.
| [reply] |
|
|
| [reply] |
|
|
|
|
| [reply] |
|
|
I hate pagination, if
- the page length is larger than the window height, so that I have to scroll and foliate
- Bonus points if sorting is implemented in-page only.
I do dislike doomscrolling, especially if I want to see the page footer (where the "masthead" lives).
| [reply] |
|
|
| [reply] |
Re^5: Ideas for PerlMonks 2.0
by jdporter (Paladin) on Dec 06, 2024 at 22:43 UTC
|
a database dump of the PM database (with the passwords and other sensitive information nuked, of course). That way i could start to design the PG schema and write a proof-of-concept importer for the user accounts and posts.
Well, how about let's instead start with PM's MySQL schema, and understand how the tables all work and tie together. There's lots of stuff there which would not need to be duplicated in the new system.
Getting "feature complete" on par with existing PerlMonks with all the bells&whistles and finetuning might take quite a bit of work (polls, XP, APIs, etc).
Exactly. That is stuff we can add once the base system is up and running.
| [reply] |
|
|
Give me a few days and i'll see if i can come up with a simple mockup/proof of concept (nothing too fancy). I should be able to get a very basic forum plus a simple wiki¹ going (hey, gotta put those list of links and FAQs somewhere).
¹ i have a wiki in some project of mine, should be easy enough to pull the database schema and configs into a new project. The forum part will use the same editor and renderer, anyway
| [reply] |
|
|
Using wiki for the site's documentation makes a ton of sense.
I hope you're using existing (cpan) software wherever possible, right?
| [reply] |
Re^5: Ideas for PerlMonks 2.0
by talexb (Chancellor) on Dec 09, 2024 at 16:24 UTC
|
I adore PostgreSQL, but I want to point out that AFAIK, pair.com only offers MySQL; they have very generously provided us hosting for years, and I'm not sure it would be wise to walk away from that. :/
Alex / talexb / Toronto
For a long time, I had a link in my .sig going to Groklaw. I heard that as of December 2024, this link is dead. Still, thanks to PJ for all your work, we owe you so much. RIP Groklaw -- 2003 to 2013.
| [reply] |
|
|
| [reply] |
|
|
I don't know the details on our deal with Pair (and i don't want to know, frankly). But i'm all for having a server on which we can install the software we want and need. Is see this as a way of future-proofing. Like, using LetsEncrypt, a full-fledged PostgreSQL database, maybe one of those in-memory search database thingies and some other modern stuff that is either available or will be invented in the next decade(s).
For example, i deploy my cash register software (based on PageCamel) to clients as docker images.
Yes, a full server does cost some money, but those things are not as expensive as they used to be. For my private stuff, i use a full server from Hetzner. It's an older model i got from their server auctions; it's got 64GB Ram, a mirrored 4TB drive and a mirrored 512GB NVMe SSD (used for database indexes and stuff), plus some additional IP addresses; all for 74 Euros per month.
We can either get the foundation or some other sponsor, or we could think of a way of paying for it as a group. Maybe pay for the privilege of posting pictures¹?.
Whatever we do, we should look into having more control over the software we run. Otherwise we'll be perpetually limited by external forces that may or may not have any interest in Perl and PerlMonks.
¹ Or, as PM is basically a sort of social network, pay for the privilege of not getting spammed with cat meme pictures...
| [reply] |
|
|