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

jdporter's site scratchpad

by jdporter (Chancellor)
on Oct 14, 2005 at 17:59 UTC ( #500336=scratchpad: print w/replies, xml ) Need Help??

  • 2007-04-21 re: overview/tutorial on packages - creation and use - We need a tut on packages!
  • 2007-05-16 how about a monitor that alerts you when one of your nodes pops up in Selected Best Nodes !
  • 2007-05-22 make a version of the site which simply uses css (classes & IDs) rather than hard-coding colors, etc., as themes do.
  • 2007-05-22 see the on-site css files
  • 2007-05-22 Note: We Stylin'!, by Petruchio
  • 2007-05-22 Note: PerlMonks CSS Examples
  • 2007-05-25 Kill [me]
  • 2007-07-17 document sourcetext page - (patch) defines a displaytype 'sourcetext' but it is not yet functional. work on this! (for Re^2: Nodes sources, and a quote tag/button)
  • 2007-07-31 try to get PerlNews section posts FrontPageable, or investigate why they can't be.
  • 2008-02-28 add a NN mode "raw", which simply lists NNs in chrono order - No sectioning, no sorting. search for 'order_nn_by'
  • 2008-04-11 Corion said ad_and_talk should be a fullpage
  • 2008-04-16 vote settings needs to be eliminated!
  • 2008-04-16 just the markup templates)
  • 2008-04-21 clinton said add a submit button to the messages form in the chatterbox sidebar. i have to pull up a full PM page in order to mark msg's as read
  • 2008-09-09 idea: a "forward" capability in Message Inbox
  • 2008-09-11 re: addnewnoteform - (patch) - In fact, all the entry fields (bottom of each section, as well as CatQ/A, and replies/comments) need their supertitles revisited/revamped
  • 2008-09-17 consider adding support for Textile markup
  • 2008-09-17 consider integrating TinyMCE for wysiwyg posting
  • 2008-10-07 give Recently Updated Home Nodes xml feed capability (and/or rss)
  • 2009-01-08 mission from Petruchio: make all wikis consistent in using either p/hr or dl/dt/dd. Then put the warning/template OUTSIDE (above) the textarea
  • 2009-01-08 other mission: make a section able to be accessed (r/w) only by a group; completely inaccessible to users outside the group. Optionally, readable by other groups in the cabal.
  • 2009-01-08 then promote these for group discussions, vice the wikis.
  • 2009-01-08 WikiModes
  • 2009-01-29 I told merlyn Your On Scalar Context has a number of replies suggesting additions/improvements but afaict you've ignored them. I'd like to get this converted into (i.e. reposted as) a tutorial. Perhaps now would be a good time to revisit those things? tia...
  • 2009-01-29 merlyn said hadn't ignored them... none of them really invalidate what i said.. just add to it. so I left the original in context (heh)
  • 2009-01-29 merlyn said sure... feel free to merge whatever you see, saying it was "inspired by the discussion at..." :)
  • 2009-01-29 I told merlyn yes, very good... for the original meditation. But if it gets reposted as a tutorial, it might be good to incorporate that stuff, so people aren't tempted to make the same responses again.
  • 2009-02-05 Re-root notes - for finding and fixing broken root linkages in replies.
  • 2009-02-05 QandAEditors Current Assignments - could use? link in wiki?
  • 2009-02-05 bad root_nodes - shows problems created by re-categorizing CatQ's!
  • 2009-02-05 Problematic CatQA replies
  • 2009-02-05 after creation of CanQAEdit, will want to patch handle_node_edits.
  • 2009-02-05 after this patch - categorized question maintenance create - (patch) - is applied, will need to create a catqalist named "New Categorized Questions"
  • 2009-02-05 integrate microformats?
  • 2009-02-23 re: Number of Monks by Level - Flip so that bars are horizontal? Some users complain that the table is too wide.
  • 2009-07-06 make a toInbox-like htmlcode for linking to NN with number of unread nodes! (if any)
  • 2009-07-20 need to make SuperSearch search sitedoclets — and map the hits back to the doc containing the sitedoclet.

datetime fields:

*Collisions: Fields with name same as above but different type:

How to move a Categorized Question:

The node_id value is the CatQ being moved; the changegroup value is the target QandASection.

How to delete a Categorized Answer:

?node_id=761527;769649=delete The node_id value is the CatQ which is the parent of the CatA to be deleted; the NAME of the delete parameter is the the CatA.

[jdporter]: usergroup display page - (patch)
[Co-Rion]: The "go to inbox" part seems not to be working
[tye]: Please don't add ubiquitous "send /msg to group" links. Please! ugh
[Corion]: Why do you feel strongly against this? Do you think the /msg volume would go up unduely?
[tye]: send a /msg to a group is one of the worst communication features of the site. we allow it for rare situations. breathers of fire have no reasonable way to know that a /msg is waiting for them.
[tye]: People should only be encouraged to /msg a group after the appropriate reasons to /msg that particular group are covered.
[Corion]: tye: Hmm - that's true, there are groups without ears
[tye]: as I said yesterday when the first patch was discussed, such links should be sitedocclan work not patchwork
[jdporter]: it appears, based on my cursory tests, that all groups do have an inbox, even the fraternal ones. So I don't see why a link to such inbox can't be shown on all group pages.
[jdporter]: my thinking is that the group page could act a little more like a "home node" for the group.
[ysth]: sure.
[jdporter]: well, apparently not all the gods agree.
[jdporter]: but I haven't heard a persuasive argument.
[ysth]: where was this discussed?
[jdporter]: mostly in my absence. :-)
[jdporter]: interestingly, none of it was posted as a response to the patch in question.
[jdporter]: SDC Wiki has some context at the top.
[tye]: yes, when people ask for feedback in the chatterbox, they get feedback in the chatterbox. twice. once by you, jdporter.
[tye]: CB history has the second conversation. And so we still don't have a response to a patch, jdporter? your criticism doesn't apply to yourself? :D
[tye]: replies are the best conversation method at the site. wikis are second worse. group inboxes are the worst of all. but I should probably /msg cabal about this instead of using the CB.
[jdporter]: well, I wasn't exactly asking for feedback. I could just as likely have been asking for someone to apply it. :-)
[tye]: the cabal inbox "exists", clearly I should be using it for something
[jdporter]: otoh, "/msg gods" is better than "/msg chromatic".
[tye]: um, /msg co-rion is obviously better when co-rion was the one who /msg'd you. let's design the site based on lame excuses of people trying to game the system and then pretend otherwise?
[tye]: and co-rion was already linked and the page linked already has a /msg co-rion link on it.
[ysth]: phrased in the positive: inboxes work great for action requests
[tye]: s/great/sometimes/
[jdporter]: the extreme negativity toward "/msg" as a communication medium makes me wonder if maybe we shouldn't go through the docs and eliminate all references to that mechanism.
[tye]: most of the "action request" in inboxes don't actually get fulfilled. it would be good to provide guidance about what type of "action request" might not be a waste of time before encouraging "/msg group"
[tye]: all of the references to it that I've read note it as a last resort. We don't need to go black-and-white. If we want to go extreme, just eliminate the feature.
[jdporter]: fair enough.
[tye]: There are a few specific cases where "/msg group" is a reasonable last choice and perhaps once case where it is the only choice (or nearly so)

setting nodes can have sitedoclets!
Currently only one does: handlelinks settings.

How does node updating work? How does the edit history work?

When I asked the gods about this, tye said:

It is a global thing. Horrible security idea. Look where the settings for fields that can/can't be updated are applied.

He is referring to the setting nodes restricted fields and unrestricted fields.

These settings are only used in Everything/, in the sub gotoNode. This sub only updates the node; it does not call any "RJE" (edithistory) related code. (See next)

The "RJE" functionality chain reads and updates the edithistory table. Updates are done via handle_node_edits, which is called (1) by the "edit" htmlpages of the sitefaqlet and doclists/docstrings nodetypes. handle_node_edits is also called (2) by node editors page. which is the "editors" htmlpage for node.

Wiki edits also cause entries in the edithistory table, but these are done (3) in the wiki editpage, which is the wiki nodetype's "editpage" htmlpage.

So it's like this:

  1. If you're in SiteDocClan and you edit a faqlet, faqlist, or faqstring, then handle_node_edits is called by the corresponding "edit" htmlpage. Similarly, if you're in Pedagogues and you edit a tutlist or tutstring.
  2. If you're in janitors and you edit any node, then handle_node_edits is called by the node editors htmlpage.
  3. If you edit a wiki, then the edithistory is updated by wiki editpage, the "edit" htmlpage for wikis.
Otherwise: the node is simply updated according to your submission, but some fields are restricted from being updateable in this way.

To create a new doclist derivative (pmdev only)

It's probably easiest to make a new doclist type by cloning an existing one, where possible. For this purpose, in the steps below, we'll clone from tutlist, as it is more "normal" than faqlist.
Cloning can only be done by gods, so where the procedure says to clone, you'll have to ask a god to do it if you're not one yourself.
Note that in all cases of cloning, replacing names and other values (e.g. group names) must be done meticulously! This aspect, however, can be done via ordinary patching, if not taken care of during cloning.

In the following example, we use "NEW" to represent the name of the new type family:

( NEWlist : NEWstring : NEWpost : NEWeds ) :: ( tutlist : tutstring : perltutorial : Pedagogues )
"NEW" is merely suggestive, and should not be substituted blindly. Use your intellect!

  1. Clone the source doclist-derived type, e.g. tutlist, into NEWlist.
  2. Clone the associated maintenance create, e.g. tutlist maintenance create, into NEWlist maintenance create.
  3. Clone the source docstring-derived type, e.g. tutstring, into NEWstring.
  4. Clone the associated maintenance create, e.g. tutstring maintenance create, into NEWstring maintenance create.
  5. Patch the maintenance create of the user-postable type which your NEWlist is intended to hold (let's call it NEWpost) so that it inserts new posts into a special "holding pen" NEWlist, just as perltutorial maintenance create does. If NEWpost maintenance create does not yet exist, create it by cloning the maintenance create of the source user-postable type, e.g. perltutorial maintenance create (editing meticulously, as always).
  6. Clone CanPedagoguesEdit into CanNEWedsEdit
  7. Patch handle_node_edits to account for the above.
  8. Patch render_doclist_group, doclist display page, doclist edit page, and Create a New User to account for the new type in the same way they account for tutlist, etc.
  9. Create a new instance of the NEWlist node type and name it "New NEWposts" (analogous to "New Tutorials"). The existence of this node is presupposed by the NEWpost maintenance create created/patched in Step 5.
  10. Add links in the appropriate place(s) — typically top of NEWeds's "how-to" wiki — to create a new instance of the type:
Here's a draft plan:
  1. switch Q&A to use doclists (catqalists) for organization (as above);
  2. add support for finding the "containing section" of a tutorial/catq at display time;
  3. cache this info;
  4. use it (link to it) at the top of catq's in place of the QandAsection link. Also add such a link to perltutorials and sitefaqlets!
  5. use it in Super Search as well, for determining whether a node is "in" the Tutorials section, or "in" the CatQA section, etc.

How Patching Works

Two things you need to know:

  1. A patch has two important fields:
    • The 'field' field: indicates which field of the node to be patched will actually be modified by the patch.
    • The 'code' field: contains the new version of the "code". This is true regardless of the type of the node being patched.
  2. You can't dump the fields of a patch unless you own the patch.

Links to other views of the Current Node:

Put this in your Free Nodelet:

This node: &#91;id://`id`] [href://?node_id=3333;parent=`id`|replyto], [href://?node_id=`id`;displaytype=xml|xml], [href://?node_id=`id`;displaytype=raw|raw], [href://?node_id=`id`;displaytype=viewcode|code], [href://?node_id=`id`;displaytype=edit|edit], [href://bare/?node_id=`id`|bare], [`id`.xml|rss], [href://?node_id=`id`;displaytype=edithistory;limit=25|rje], [href://?node=`title` sitedoclet|doclet], [href://?node_id=`parent_id`;displaytype=xml|parent as xml], [`id`|on DEV], [`id`.xml|orig(xml)], <a href="`url`" id="page_url">url</a>

Overriding the Level Requirement for Home Node Pics

As documented in How do I change my home node?, the site restricts the ability to have a homenode pic to users of at least Level 5: Beadle. This is implemented in accessule CanHaveImage and manifested in user display page and user edit page.

However, this accessrule also implements a trap door which lets specific, blessed individuals have a homenode pic even though they don't meet the minimum height requirement. This is documented in I want my picture back, and refers to the settings home node image cheaters (which should probably have been implemented as a usergroup, not as a setting).

Apart from the original purpose of granting homenode pic amnesty to early cheaters, this is used to give certain non-player characters a homenode pic, since it may be useful to their errand, though it involve no monk level attention. If you have a non-player character who you feel should have a home node image, you may request (via /msg) that the gods add it to the list. If you do, expect to get a lot of pushback.

How to create a new node of arbitrary type

pmdevils can't do it directly. We need to invoke the gods.
In essence, we ask them to make a new, empty node of the desired type, then we submit a patch to populate the node with its initial contents. Practically, these can be done in the same step. The traditional, preferred way to do this is to submit a patch against the special node
request for new code node.
(In actual fact, it doesn't matter what node the patch is submitted against. At the time of applying it, the god will "re-direct" it to the new node you asked for, regardless of where it was originally.)
In addition to the desired node title and content, you must also communicate to the gods precisely which nodetype you desire for the new node. Therefore, it is recommended that the "reason" you give on the patch be formulated as follows:
nodetype: exact node name
For example:
fullpage: node navigator ticker

It is also advisable, in most cases, to immediately reply to your patch with a comment explaining the rationale for the new node in more detail.

Note that when the new node has been created and the patch applied to it, the patch will no longer be listed under request for new code node and will be listed under the new node (when viewing its code).

To see what happens, look at this patch I wrote: unused fullpage - (patch).
I originally wrote it against unused fullpage, but it was applied against the new node, node navigator ticker.
You can see the patch listed under the latter, but not under the former. The patch's title (not reason) still suggests that it was written against the former. That's a little confusing, but ultimately immaterial.


You know you can select a displaytype other than the default by adding ;displaytype=type to the URL. For example, to get the XML view of a post, add ;displaytype=xml.

Where are these types defined and implemented? What displaytypes are available for any given nodetype?

To find what displaytypes are defined for a nodetype, simply go to that nodetype's definition page and look at the list under Relevant pages. For example, see the definition of the note nodetype. The first column is the name of the displaytype (e.g. xml, edit, print, and so on) and on the right is the corresponding htmlpage which implements the displaytype. The htmlpage naming scheme, which is a convention from Everything, is "nodetype displaytype page". See the full list of htmlpages.

Note that htmlpage is a node type, with its own database table. One of the fields in the htmlpage table is pagetype_nodetype. This points to exactly one of the many node types. This htmlpage can be applied to (used on) that node type or any of its derivatives, down to the point where it is overridden by a subtype. To see the value of this field for a given htmlpage, view the htmlpage's page. E.g. node print page shows pagetypenode, while obfuscated display page shows pagetypeobfuscated.

To define a new displaytype, you'll need to create the corresponding htmlpage. See ⇒Creating a display htmlpage.

It is definitely best to request cloning of an existing htmlpage, because several fields have to be set by things you can't touch via a patch, such as pagetype and displaytype. Be sure to state in your supplication what the new value of these fields should be.

To see where these things are used, look at sub getPageForType in Everything/

Not All Database Tables are Used Directly in Node Type Definitions

There are 87 dbtables in total. Some are used by nodetypes, but most are not. And some, of course, are not used at all.

dbtableused in nodetypes
containercontainer, theme container
contributorcategorized question, categorized answer
documentdocument, note, restricted_superdoc, superdoc, user, usergroup, perlquestion, perlman, data, perlmeditation, perlcraft, fullpage, perlfaq nodetype, meta-user, mail, perltutorial, perlexercise, perlsolution, monkdiscuss, CUFP, superquestion, superquestionarea, poem, obfuscated, sourcecode, categorized question, categorized answer, rawpage, strangedoc, request, quest, testquestion, hint, sectioncontainer, sitefaqlet, strangenode, review, perlnews, testtype, modulereview, bookreview, sillyscript, wiki, includefile, pmdevsuperdoc, devtask, scratchpad, css, Dynamic CSS, pmdevnote, sitedoclet, pmdevtopic, sqlquery, offtopicroot, script, faqlist, alphafaqlet, tutlist, doclist, zombie_user, catqalist, public_sqlquery, locked_user, wonki, devdoclet
htmlcodehtmlcode, maintenance, opcode, patch, sqlquery, accessrule, public_sqlquery
nodenodetype, container, document, htmlcode, htmlpage, image, node, nodegroup, nodelet, nodeletgroup, note, rating, restricted_superdoc, superdoc, user, usergroup, perlquestion, perlman, string, data, perlfunc, perlmeditation, perlcraft, fullpage, linktype, perlfaq nodetype, dbtable, file, maintenance, meta-user, nodeball, setting, mail, bug, perltutorial, perlexercise, perlsolution, theme container, monkdiscuss, CUFP, theme, themesetting, poll, superquestion, superquestionarea, poem, obfuscated, sourcecode, sourcecodesection, QandASection, categorized question, categorized answer, snippet, rawpage, opcode, strangedoc, request, quest, testquestion, hint, sectioncontainer, sitefaqlet, strangenode, review, perlnews, testtype, modulereview, bookreview, sillyscript, wiki, includefile, pmdevsuperdoc, devtask, patch, pmmodule, rawdata, scratchpad, css, Dynamic CSS, pmdevnote, sitedoclet, pmdevtopic, sqlquery, offtopicroot, script, reaped_snippet, faqlist, alphafaqlet, accessrule, tutlist, faqstring, testpoll, docstring, doclist, tutstring, zombie_user, restricted setting, largedoc, catqalist, catqastring, public_sqlquery, locked_user, wonki, godstring, devdoclet
notenote, perlsolution, categorized question, categorized answer, pmdevnote
rawpagerawpage, css, Dynamic CSS, script
reviewreview, modulereview, bookreview
settinguser, meta-user, nodeball, setting, theme, themesetting, sqlquery, faqlist, tutlist, doclist, zombie_user, restricted setting, catqalist, public_sqlquery, locked_user
snippetsnippet, reaped_snippet
stringstring, linktype, faqstring, docstring, tutstring, catqastring, godstring
useruser, zombie_user, locked_user
wikiwiki, wonki

Hint on Patching Strange Nodetypes

When you view nodes of certain types (such as css; example: Blue web-safe CSS), they're shown as "raw" data, with no containers or other usual PerlMonks decorations. Suppose you wanted to patch such a thing. How can you get to that function?

Try adding ;displaytype=viewcode to the URL, e.g. /?node_id=204962;displaytype=viewcode

The other thing you can do is go to Node Lister, and filter for the type you're interested in (e.g. list nodes of type 'css'). Next to each node listed is a 'viewcode' link.


The VARS hash: What is it? Where does it come from?

VARS is actually a hashref. By default, it is loaded at page load time from data associated with the current user (you). (Look for sub confirmUser)

The function that actually loads a "vars" hash for a given node is sub getVars. The node must already have been loaded into memory. It looks for data in the 'vars' field of the node. For there to be a 'vars' field, the node must be of a nodetype which has a 'vars' database field. Only one db table has a field named 'vars': setting.

But wait - user isn't a setting node! Is it?

Yes, it is! If you take a look at the definition of the user nodetype, you'll see it actually joins three different db tables: user, setting, and document.

Although $VARS is loaded automatically for the current user, htmlcode can get the "vars" for any user. For example:

$num_writeups = getVars( getNode($user_id) )->{numwriteups};

So you're probably wondering: What other nodetypes might have "vars" (besides, obviously, setting) by virtue of joining the setting db table? There are a few (scan Type Tree), but an interesting one (IMHO) is doclist, or rather, its two subtypes, faqlist and tutlist.

Usage of %HTMLVARS

See the Pmdev HowTo Wiki for an explanation of what %HTMLVARS is for.

%HTMLVARS is loaded by Everything/ using set_htmlvars. It loads the data from system settings. (It also reads the contents of htmlvars nodegroup, but this data is dropped into the bit bucket.)

Tips for the new PmDevil

The pmdev group is actually one of the safest groups to be in, in terms of being able to commit destruction to the site. That's because the only thing you can do is write patches: unless/until a god applies the patch, it has zero effect.

The Everything structure is pretty complicated, to be sure. To gain familiarity with it, you pretty much just have to keep slogging through nodes, through code, manually tracing function calls. The wall I hit is about the database and various related things that are still opaque to pmdevils.

How should a new pmdevil get started?

The very first thing to do is enable the PmDev Nodelet, of course. That should almost go without saying. I would also enable the Cabalists Nodelet, if you haven't done so already.

The various pmdev wikis are good resource, of course. You should read at least these:

It's really essential to understand about node types. You can start at Type Tree (linked in the PmDev Nodelet as "Types") and browse around. Also check out "chromatic's library" (linked in the PmDev Nodelet); it has more info than you'll ever need, but the first five links in the list are essential. (Update: is now gone. But the contents are preserved in the Wayback Machine.)

Many types of nodes are patchable. Primarily there is htmlcode; it's the real workhorse nodetype, essentially a subroutine in the Everything framework. There are several other code-like and template-like nodetypes. Then there's settings, which are data tables. So choose some of these, read the code, and read some of the patches people have written against them. For a (not quite random) example, go to The Monastery Gates and click on the 'code' link. You see the code formatted with line numbers, then the code in a text edit box, and then a table of all the node's patches. (Btw... when you're viewing a nodetype, either on its own display page or within the Type Tree, it has a link to a listing of all of the nodes of that type. That is very handy, in my experience.)

As you browse around the code and start to get familiar with perlmonks' workings, you'll encounter certain basic subroutines time and again. In most cases, such subroutines are defined in nodes of the same name. For example, parseCodeInString. Nodelets are defined this way as well — for example, PmDev Nodelet. So, as a first resort, you can type/paste the name of the sub you're curious about into the Search box.

Failing that, you can use the Search internal code tool (linked in the PmDev Nodelet as "Search code"). This tool is truly your friend.

You'll eventually discover that some of the code that runs the site is not in patchable nodes. I'm referring to pmmodule nodes (see near the bottom of the Type Tree page). Most important is Everything/ Many of the most fundamental functions that you encounter in pm code are defined there. You'd do well to be familiar with it. E.g. say you're trying to find the definition of sub linkNode. There's no linkNode node! That's because it's defined in Everything/ (Search internal code would find it there, but many other places besides.)

pmdev notes

Some node types are ultimately just html. With templating features, of course.
The node types in this category include superdoc, fullpage, and htmlpage.
Note that superdoc and fullpage are sub-nodetypes of document.
(document, htmlpage, and htmlcode are not related. That is, their closest common ancestor is node.)

The templating syntax uses three flavors, all based on square brackets:

  • ["perl string"] evaluates simply to the given string. It's a perl string literal, so it does interpolation of variables etc.
  • [{code_call}] or [{code_call:arg1,arg2}] evaluates to the result of calling the code contained in the htmlcode node named code_call.
  • [% full perl code here %] evaluates to whatever the given perl code evaluates to.
In each case, the square-bracketed expression is replaced in the html with the string resulting from its evaluation.

Here's a node which happens to use all three: patch display page

Nodes of type htmlcode contain straight perl code, not html.
Sub-nodetypes of htmlcode are opcode, patch, and accessrule.

How To Add a User Setting

It's really not complicated:

  1. Make up a name for the new variable. E.g. show_id_on_note.
  2. Decide which type of variable it should be, e.g. checkvar is a boolean, which gets rendered as a checkbox.
  3. In Display Settings (for example), add something like [{checkvar:show_id_on_note}]
  4. Use it in node code as an element of %VARS. E.g.
    ( $VARS->{show_id_on_note} ? " [id://$NOTE->{node_id}]" : "")
(The example above is taken from Display Settings - (patch) and shownote - (patch).)

The available htmlcodes for form input elements are:

See each one's code for a description of optional arguments.

(Note: [{varmenu}] is not a general-purpose form input widget; ignore it for now.)

How to embed a sitedoclet in another node

An example can be seen in the code of Create A New User, which embeds Choosing a username.

The basic formulas are as follows.

For embedding in the template types (superdoc, fullpage, htmlpage) —

[{get_sitedoclet}] # use default doclet selection [{get_sitedoclet:Choosing a username}] # select specific doclet
For embedding in Perl code, e.g. within [%....%] blocks and in htmlcode nodes —
$html .= htmlcode('get_sitedoclet',...);

get_sitedoclet is quite flexible. Read its code, which has embedded doco.

Note that the get_sitedoclet doco also includes critical information on the formatting of sitedoclets, which SiteDocClan will find highly pertinent!

If the first arg (the sitedoclet node title) to get_sitedoclet is omitted (i.e. false), a default title of "Foo sitedoclet" is used, where "Foo" is the title of the node being rendered, i.e. the node in which the sitedoclet is being embedded.

Also, it appears that the first arg can be a node ID instead, since getNode has been enhanced to defer to getNodeById if the title given is a string of digits.

Another htmlcode you can use instead of get_sitedoclet is showsitedoclet.
showsitedoclet differs from get_sitedoclet only in that it adds some "decoration" to the rendered doclet: If the user is in SiteDocClan, it adds an "Edit" link (or a link to create the doclet if it does not yet exist); if the user is not in SiteDocClan and there is no doclet, a "no such sitedoclet" message is inserted at the top.
Currently this is only used in two spots: in displaying usergroups and in displaying accessrules. Because of the rather annoying message shown to Poor Ol' Monks when there is a missing sitedoclet, use of showsitedoclet should probably be carefully considered.

How to control user access to a node?

You make the following call, which returns a boolean:

Everthing::isApproved( $USER, $AccessControl );
Where $AccessControl is the ID of either a usergroup or an accessrule. If it's a usergroup, isApproved will return true if the user is in the group. If it's an accessrule, isApproved will return whatever the accessrule returns. An accessrule contains an arbitrary chunk of perl code (rather like an htmlcode) which should return a boolean. See the existing accessrules for an idea.

isApproved is defined in Everything/

Generating XML

The function to use is new_xml_fling (uses). This supercedes XML::Fling (defined in XML/ which is still in use in a significant number of nodes. Note that XML::Fling itself is not going away; new_xml_fling calls it!

Observe that the current uses of new_xml_fling are either in fullpage nodes, which generally have "xml generator" or "xml ticker" in the name, or in htmlcode nodes, which means it's being wrapped in another function.

pmdev links

Mentioned in pmdev wiki through 2004-10-25.


For pmdevils, the pmdevTEXT is displayed, and links to the given target. For everyone else, the othersTEXT is displayed, and is not a link.


[pmdev://42|secret magic node|Poor muggle] = Poor muggle

demerphq in the cb, on 2005-10-25 saith:
so [pmdev://14] will show a link to pmdevils, and just text [pmdev://14] for everybody else.
[pmdev://foo|bar|baz] acts like [foo|bar] for pmdevils and as simply baz for non pmdevils.
the original reason was i wanted links to source code on the xml ticker list. but i didnt want normal users to see links that would lead them to a tough beans. its use in chatter was just a bonus.

The basic page framework

...information lost!...

Replies are listed 'Best First'.
Log In?

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

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (3)
As of 2022-08-14 13:27 GMT
Find Nodes?
    Voting Booth?

    No recent polls found