Looking back over the patches for the last few years, it strikes me that despite lots of patches, mostly from jdporter, there has been lots of good fiddling around the edges. The biggest flaws in The Monastery remain. I believe these are turning people away from The Monastery.

I would like to propose what I think are three priorities that would be a step change for The Monastery without removing any of it's existing strengths:

  1. WISIWIG editor for posting along the lines suggested by cavac in WYSIWYG editor
  2. A revamp of the main menu navigation bar
  3. Address the issue of unencoded passwords

I am not suggesting someone else does the work to make these happen. They are all things that I have implemented on other sites multiple times. However, I don't have the knowledge of PM's codebase or sufficient access for some of these. So I would need help to make them happen.

We only have to look across to Everything2 to see how relatively small changes can have a big impact on user experience

Javascript

I'm going to preempt an objection...that 1 and 2 would require Javascript and not everyone has it enabled.

A few years I ran a test on one of my sites to see how many people have JS switched off. After over 700k visits, less than 0.2% has JS off. But, I accept that PM is mostly frequented by older developers (me included) who are more likely to switch off JS.

But whilst JS is needed to make WYSIWYG functionality, we can have a user setting to switch back to the existing raw-HTML editor and also do that switchback automagically if JS is not enabled on the user's browser.

None of this is new...but is there any mileage or appetite for addressing it now?

Replies are listed 'Best First'.
Re: Priorities perhaps?
by Corion (Patriarch) on Feb 02, 2024 at 10:41 UTC

    In principle, Crypt::Passphrase would be a good way to approach the passwords stored here, but the main work is in ripping out the hardcoded password logic in the Everything engine, and also replacing the "we send you your password" with a proper "confirm to reset your password" mail+workflow.

    This wouldn't be especially hard but it is a lot of work that needs to be complete before switching over.

[reply]
      > with a proper "confirm to reset your password" mail+workflow.

      I can provide that, see Re^2: Priorities perhaps? (Password reset)

      (Alas these impromptu private pmdev talks are not really suitable to discuss this, b/c there are no notifications or RAT views.)

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

[reply]
        Alas these impromptu private pmdev talks are not really suitable to discuss

        Do you have any suggestions to improve the discussions?

        I'd be happy to set up a WhatsApp group or a private Facebook group for cabal members who wanted to be part of it...

[reply]

      My usual way of approaching this is to encrypt the password with the sha512_base64 method from Digest::SHA. I then generate a random 40 character string to salt the password. The random string gets changed when the user changes their password. I split the 64-character encoded password into two parts and insert a hash of the salt. I split the encoded password a different place for each site I write.

      I reckon that's pretty unbreakable without access to the codebase.

      But, the difficulty isn't encoding the passwords or storing passwords and possibly salts.

      As you rightly point out, the biggest difficulty is that we can't just send out encoded passwords. Once encoded, users need a means to select a new password, and that means a whole new workflow needs to be created. It's simple enough to do but there is quite a bit of work. Another issue is that it would be difficult to properly test without a test server but certainly not impossible.

[reply]
[d/l]
Re: Priorities perhaps?
by choroba (Cardinal) on Feb 01, 2024 at 22:38 UTC
    I'd love to see (and maybe even help) get #3 fixed. It should be the top priority.

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]
      I already have a secure perl cgi to request a password reset link mailed to a client.

      This could be adapted for the monastery.

      It's heavily tested and already ran for 8 years without issues.

      The problem is rather that pm-devs don't have access to all the code here, not speaking of the servers, the database or even having a test environment.

      Furthermore will the gods need to figure out what needs to be changed to run the monastery with encrypted passwords.

      There are also "keep-me-logged-in" cookies needed to be adapted. No idea what needs to be done here.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

[reply]
        The problem is rather that pm-devs don't have access to all the code here, not speaking of the servers, the database or even having a test environment

        There are plenty of problems...you raise very valid ones.

        However, things change when we focus on solutions, not problems.

        It appears that we have two gods on board - the alter-egos of jdporter and Corion. With the enthusiasm and effort of a few pmdev's coupled with the power of a couple of gods, surely we can bring about this change...

[reply]
      I'd love to see (and maybe even help)

      Lots of people would love to see this...
      Only a few can make it happen!

      It should be the top priority

      I agree it should be top priority. However, there are two reasons I didn't list it as #1

      • It doesn't improve the user experience (until there's a password breach)
      • It is the furthest away away from my access and abilities within the PM ecosystem
[reply]
Re: Priorities perhaps?
by jdporter (Paladin) on Feb 02, 2024 at 12:16 UTC

    Thank you, Bod! #2 should be fairly easy, depending on how we want the new menu to look / work. I don't recall there being any discussion about this, however. At one point, I started working on a "mobile" version of the site (see Development of PerlMonks "Mobile" is now open for business), and this would have a js-powered pull-down menu in place of the static 'bar' at the top. Further development stalled due to lack of - er - "resources".

    To address the need behind #1, I started working on a feature whereby users can post in markdown (or, potentially, any other markup language, e.g. bbcode, POD) and the system would automatically convert it to perlmonks markup. See Markdown is now supported for comments, experimentally. However, work stalled; see here.

[reply]
      #2 should be fairly easy, depending on how we want the new menu to look / work. I don't recall there being any discussion about this

      Hidden back in the mists of time, LadyAleena raised the topic...I can't find the node but she produced a mockup menu

[reply]

        Thank you. Super Search finds it easily enough: Title bar and menu face lift? (NB: Lady_Aleena) Seems to me that's little more than styling - something one should be able to do with CSS. I, for example, take the main menu and shove it into a nodelet using CSS+JS.

[reply]

Back to Perl Monks Discussion