Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Perl Monks Discussion

( #1040=superdoc: print w/ replies, xml ) Need Help??

This section is only for discussing issues pertaining to the PerlMonks web site. You can ask about how things work, or offer ideas on how the site could be improved, for example.

Unless the topic pertains to the PerlMonks web site, it does not belong in this section. If you're unsure, check out Where should I post X? and The Perl Monks Guide to the Monastery, or ask in the chatterbox.

PerlMonks Discussions
Code tags vs Readmore
4 direct replies — Read more / Contribute
by chacham
on May 23, 2014 at 07:20

    There are a couple things i wonder about, from time to time, about the code tag. One, the width makes a lot of code wrap when on my screen there is no need. Two, code can get longer and i wish it were a readmore tag instead.

    The code tag seems to wrap at 70 characters, is that to support terminals? Perhaps that could be an option, so those with wider screens have the option of seeing it unwrapped.

    The readmore tag is intended to keep a post from being too long. Yet, though a code tag pretties it up, it does not shorten it. Leaving it long certainly allows for quicker reading on the page, though it hinders getting to the start of the next post.

    Just some thoughts.

Some more modern forum engine?
6 direct replies — Read more / Contribute
by llancet
on May 03, 2014 at 22:44

    As a user, I think there are at least two disadvantages on the design of perlmonks forum:

    There are too many objects on the right side.

    Does not support uploading pictures.

    It seems the use of JavaScript are avoided. Is it the reason that we can only have such plain pages? Maybe you can find some forum engine which can render two sets of pages: one only plain HTML, the other one with the full use of CSS, JS, HTML5, etc.

Permission Denied?
3 direct replies — Read more / Contribute
by Anonymous Monk
on Apr 28, 2014 at 14:38

    Dear Monks,

    Sometimes when I try to post (reply to a question, most recently this one), I get the Permission Denied page, without any particular explanation. Any idea as to why?

    This does not happen on the Preview, which makes it somewhat frustrating to have just typed up and proofread a response and then not be able to post it.

    Thanks in advance.

chk boxes in chatterbox
2 direct replies — Read more / Contribute
by HarryPutnam
on Apr 25, 2014 at 18:10
    What is supposed to happen when you check the boxes in chatterbox?

    I took it to be some way to make sense of the confusing flow of messages in various thread, and assumed once checked, that box would disappear, allowing you to keep up with the responses you've read

    After fiddling with it for a while... I really don't see what it does at all.

Some better way to read/post/follow threads
2 direct replies — Read more / Contribute
by HarryPutnam
on Apr 25, 2014 at 18:01
    There seems to be a real wealth of knowledge on PerlMonks.

    I'm quite a new user... and find the interface for reading and posting in threads is difficult to follow. After just scanning briefly thru some of the setup stuff, I saw no section devoted to how threads are presented.

    Hopefully I'm just blind to seeing how to set things up in some way I can follow better. If so I hope some kind Monk will steer me toward the relevant information.

    Is it possible to connect with the various forums, thru NNTP? And use them like regular usenet is setup?

    Is it possible, thru personal settings or whatever to get my group reading interface to resemble the one available on gmane. With Frames and threading so the groups appear in the tried and venerable style of usenet

Pretify the site with CSS?
5 direct replies — Read more / Contribute
by Anonymous Monk
on Apr 23, 2014 at 14:12
    Can you suggest and share some custom made CSS examples that make Perl Monks more pleasing to the eye and easier to read ?
OpenSSL Status
2 direct replies — Read more / Contribute
by papidave
on Apr 19, 2014 at 18:33
    Inasmuch as Heartbleed is forcing admins all over the internet to patch their servers, and inasmuch as it's considered wise to change one's passwords after said patching, I'm wondering if PM:
    1. was ever vulnerable to the OpenSSL issue known as Heartbleed, and
    2. if we're all patched, so I can reset my password.

    Thanks muchly,


propose updating node about linking to cpan modules
4 direct replies — Read more / Contribute
by Lotus1
on Apr 16, 2014 at 11:34

2 direct replies — Read more / Contribute
by milan.dalwadi
on Apr 11, 2014 at 03:07
    To front page or not ? [ANSWERED]
    5 direct replies — Read more / Contribute
    by Bloodnok
    on Apr 10, 2014 at 06:35
      Greetings fellow approvers,

      Pray tell, what are the considerations &/or constraints to be applied when deciding whether, or not, to front page a node ?


      Many thanks to the respondents - it's all much clearer now ... for a Friday :-)

      A user level that continues to overstate my experience :-))
    "Message Inbox" is not displaying messages
    2 direct replies — Read more / Contribute
    by kcott
    on Mar 06, 2014 at 21:13

      My Message Inbox is indicating "Inbox (2)" but no messages are displayed.

      I can see both messages in the Chatterbox section.

      I've tried accessing the Message Inbox via the following links:

      •;srch_folder=0: the "And 0 more" link in the Chatterbox section.
      • the "... private messages ..." link in Message Settings.
      • the "... Message Inbox ..." link in Message Outbox.

      Logging out and back in again didn't fix it.

      I also tried logging in to and no messages were displayed in the Message Inbox using these URLs.

      -- Ken

    Avoiding accidential reposts
    3 direct replies — Read more / Contribute
    by LanX
    on Feb 25, 2014 at 17:24
      This is not a feature request!

      ... more a meditation. :)

      If we'd supply a unique id for each comment session, could this be used to reject or warn about accidental reposts?

      I.e. after clicking "comment" a hidden field would contain something composed from parent-node-id + user-id + timestamp + random number and passed thru the "preview" and "create" stages.

      After first posting this ID could be "disabled". Either by storing in the DB-table holding the final post or by caching it for x hours.

      A considerable part of NTCs deals with such accidental duplicates and even experienced monks regularly fall into the trap (especially when using mobile clients)

      Am I missing something?

      If this was already discussed before please point me to the discussion.

      Cheers Rolf

      ( addicted to the Perl Programming Language)

    Thanks to the Perl Monks
    No replies — Read more | Post response
    by shirkdog_perl
    on Feb 05, 2014 at 02:26

      Since 2002 for me, this place has been a refuge, now more than ever from all of the garbage we now call "The Internet". I am delighted to see new posts with active discussions.

      A thousand blessings to all monks on their journey through Perl.

      Shirkdog is meditating...

      #!/usr/bin/perl -w use strict;
    Message Inbox: Retain Deleted messages longer
    1 direct reply — Read more / Contribute
    by jdporter
    on Feb 04, 2014 at 21:38

      My hallucinogenic memory tells me that I read, somewhere, a long time ago, that any messages in your 'Deleted' folder get purged every day, or something like that; and my experience certainly seems to bear that out.

      Can we please change that to a week, or at least several days? Thanks you!

      (And if anyone can tell me where the code that implements this is -- and if it's a code node -- I'd be happy to code the implementation myself.)

      I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
    Having our anonymous cake and eating it too
    9 direct replies — Read more / Contribute
    by pemungkah
    on Jan 23, 2014 at 00:52
      I mentioned this in another thread, and Anonymous Monk kindly suggested I float it in its own thread - so here we go.

      The problem at hand re anonymous users is that some people really really love Anonymous Monk, and others really really don't. There are certainly folks who are very vocal about this both ways and who continue to be; the consensus has always been either anonymous posting must completely stop forever and the Anonymous Monk be eliminated, or anonymous posting must be left as it is because it is too difficult to do anything about it.

      I'd like to propose a possibility that might let both sides of this discussion have what they want - it it obvious that there is at least some dissatisfaction with anonymous posting as-is, and it's also obvious that we're not going to eliminate a feature which is very popular with many.

      (Those who understand the internals of the Perlmonks engine, bear with me; I've not seen the code, so I do not yet know if this is feasible. If I'm incorrect, let's talk it over and see if the concept is something we can work with, even if my specific implementation guesses are not.)


      1. We keep the Anonymous Monk. This is, from much reading here, not negotiable.
      2. There are, from time to time, personality conflicts among the members of this site. This is simply a fact.
      3. At times, some people may not want to see postings from others, either selectively, or at all.
      4. Any proposed solution must not alter the current functionality's default operation.
      5. Any suggestion must be as small as possible a change.
      This seems like a difficult set of criteria to meet without altering the most basic characteristics of the users - but let's look at this from a different angle. What if we made "allow anonymous users to respond" to be a characteristic of a node instead?

      We'd default this characteristic to be on unless turned off. If turned off, all child nodes of this node would inherit the characteristic (whether by data inheritance or plain old copying is an implementation detail - suffice it to say that the characteristic would be added to each node, and only the first node in a new thread would have the option of setting this characteristic - for simplicity, if you started out open, you don't get to "take it back"). All child nodes would retain the parent's characteristic, and would not be allowed to alter it. However, if node characteristics are truly inheritable from a root-of-thread node, then "taking it back" is possible (what is my root node's current "allow anonymous" setting?), and a nice thing to permit. I do not think nodes should be pruned if this setting is changed; that adds too much complication.

      Alternatively, each top node could have a pointer to the originator's "block list". Checking a "no anonymous replies" checkbox in your home node adds the Anonymous Monk to this list; a secondary input field/page in the user's home node settings would allow them to add other ids to the block list (probably stored as home node IDs). Each new thread would copy/inherit the block list from the user to the root node - probably copy, as we don't want the changes to propagate across large swaths of the database if someone posts a lot then alters their block list. Each subsequent child node would continue to receive this block list.

      Users who did not want to block the anonymous monk would leave the box unchecked (and if the block list exists, would have an empty block list); this allows them to use Perlmonks in the style to which they are accustomed.

      Users who want to block other monks (whoever this might be) would add them to their block list (or check the box), and they would no longer have to see posts from those monks. Blocked monks would receive a polite "monk prefers not to see your posts, sorry" message when trying to post to a node/thread on which they are blocked.

      Considerations should not be blockable; I'm on the fence about votes. Needs discussion to tease out the positives and negatives here.

      Let's please not simply say declare it impossible; let's think about it and see if we can partly do it if the whole idea doesn't work. If there are architectural issues, let's look at them and see if there are any further ideas that might let us move forward in a different way with the same kind of function.

      It just comes down to each monk being allowed to control what they wish to read, which is a reasonable goal. Let's see if we can find a way to meet it. I am more than happy to do (and capable of doing) work to make this happen.

    Discussion Item
    Give us your input:
    Use:  <p> text here (a paragraph) </p>
    and:  <code> code here </code>
    to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others chilling in the Monastery: (10)
    As of 2014-10-20 22:14 GMT
    Find Nodes?
      Voting Booth?

      For retirement, I am banking on:

      Results (92 votes), past polls