Not all of the below are properly documented. jdporter expressed interest in remedying that situation. This was a quick way to get the information available to anyone who wanted to contribute...

As a mere Clansman, I hereby humbly submit a request that a sitedoclet be created for each superdoc which heads a site section (e.g. Seekers of Perl Wisdom).

This is so we can write text to go at the top which says what the section is for. (An example of a section which has such intrinsic doco is Perl Monks Discussion.)

I've been told that "creating sitedoclets is the easy part; each of the superdocs would have to be patched so that it uses the sitedoclet."

Perhaps a script could be created that does the sitedoc patching bits at the click of a button?

Thanks!

I'd like to propse the following (untested) code as how isApproved() and isGods() should behave. The idea is to make isApproved() more flexible by allowing it to take a string as the second argument, its adds a third argument to allow accessrules to operate on a "per-node" basis. It also sets up a return set of data in the $HTMLVARS{isApproved} that can be used by the caller to obtain information about why the user was not approved.

The most important thing is the per session caching of isGods() and isApproved() lookups. I've noticed that when you review the code these two routines get called many many times. Caching them per session will mean that this overhead is considerably reduced. Despite the way the caches look (HoH and HoHoH) I beleive that per session they will have relatively little data in them. And since %HTMLVARS is reset every session I dont beleive we have data synchornization problems or the like.

Anyway, comments appreciated. Also, i say the code is untested insofar as I havent actually put it into play and tested it on the pmdev server. It does compile, and seems to behave as expected in the dumper prompt and should be pretty close to bug free.

BTW, i was considering a fourth argument to isApproved(), a flag that would determine if gods should really always be approved. If the flag was true then the gods would only be approved if the gods were in the group, otherwise the behaviour would remain unchanged. IE when this flag was set the result would be a true membership/rule check and not implicitly put the gods in every group.

Update: Testing on the pmdev server indicates there is a flaw in the code below. I need to figure out what it is. /gah Ok, all fixed now. This code is running on the test server right now. Also there is some instrumnetation code in there to determine how often the cache is used, and how often the two subs are called. On the dev server there is code to see the results, and in my testing around 85% or more of the calls were resolvable from the session-cache. The sample total was 42 calls, with 36 in total resolved from cache. When you look to the two seperately, the numbers were 1:7 for isGods and 4:30 for isApproved. IMO this makes it clear this is an improvement. I have to say the feel of the site on pmdev seems to be more responsive too.

They'd need to be applied in this order

1. parse_snippet_desc - (patch)
2. listapproved settings - (patch)
3. Snippets Section - (patch)

Any feedback much appreciated.

I applied the following patch on the pmdev server,

--- NodeBase.pm.orig    2005-08-21 11:22:05.250000000 +0200
+++ NodeBase.pm    2005-08-21 18:33:38.859375000 +0200
@@ -2031,9 +2031,18 @@
 
     #you're always approved if it's yourself...
 
-    foreach my $approveduser (@{ $this->selectNodegroupFlat($NODE) })
+    foreach my $node (@{ $this->selectNodegroupFlat($NODE) })
     {
-        return 1 if ($user_id == $this->getId($approveduser));
+        return 1 if ($user_id == $this->getId($node));
+        if ($node->{rulecode}) {
+            my $res=eval $node->{rulecode};
+            if ($@) {
+                #logit danno
+                Everything::printLog("Rule error in $node->{node_id}:
+$@");
+                # return 0; # should this happen?
+            }
+            return $res if defined $res;
+        }
     }
 
     return 0;
[download]

and created a new dbtable and nodetype 'rule', with the following structure:

CREATE TABLE rule (
 rule_id int(11) NOT NULL auto_increment,
 rulecode text,
 PRIMARY KEY  (rule_id)
) TYPE=MyISAM
[download]

An 'edit' display page and a 'display' display page cribbed from htmlcode, along with a tweak of patachable fields completed my modifications. All together they allow arbitrary rules to be added to usergroups, which when encountered by isApproved() will be executed and used to control the access.

Advantages: Very simple change to code with far reaching effects, very flexible. Disadvantages: requires usergroup wrapper even if you only want a rule. Requires added table.

IMO this would be a good addition to PM. I was thinking that the documentation for the nodes would be provided by the 'display' page showing a sitedoclet if one existed, possibly via a generalized 'add a sitedoclet to this' mechanism that could be reused elsewhere.

I imagine the process as follows:

1. The janitor clicks retitle in the Editors Nodelet
2. A Textbox is displayed. Janitor enters a new title and clicks preview.
3. The new thread titles are displayed
4. The janitor clicks submit
5. The nodes get retitled and unconsidered
6. An editorial note is left in the first retitled node that includes the consideration, the considerer, the janitor and the number of votes (Keep/Edit/Delete)
7. Textbox and button are displayed for a autogenerated /msg to the OP

retitle/defalt/default/
[download]

retitle/*/This is a new title/
[download]

I'm interested in hearing your opinions.

As a separate question, should nodes out there that were nuked via editor vote be reinstated as reaped nodes? There are more than 600 of them, but only 2 of those are nodes created in the last year.

Ive implemented a new displaytype called 'selectcode', its supposed to work in tandem with 'displaycode'. The new htmlcode node selectcode and the existing extractcode now work together to allow the user to select which code blocks should be downloaded.

IMO a future direction is a user option to put links underneath block code sections to allow that specific block to be downloaded directly without requiring use of the selection code. But until that is done the selectcode page and links will prove useful IMO.

Ive put a switch in that allows you to ignore 'inlined' code blocks by default, although currently the setting is only available from the selectcode view. It should also be added to the appropriate User Settings page.

As usual there are probably rough edges in this stuff, so patches welcome.

You can use this node to test, here is some inlined, here is some in c-tags and here is some block code:

print "Hello World!";
[download]

and some more

print "more" for 1..100;
[download]

Note the additional link at the bottom of the node: 'Select Code To Download'

Some pmdev members are testing the new node cache. Message inbox and pmdev's wiki both suck for discussions. So problem reports and such should go here.

The new node cache is pretty much a complete rewrite which gives us about two- or three-times more efficiency when reading nodes and tons more efficiency when updating nodes (fifty-times in a simple, realistic example) and reduces the race conditions to where they should no longer matter.

I'll post more details, explanation, and even the code later.

Thanks,

Its been a long term objective for a few of us in pmdev to renovate User Settings. The node is too big with too much clutter which makes it hard to use and fairly annoying to work with. Some of this work is already done and some of it is partially done, with all of it up for reconsideration pretty much, at least in my opinion. Currently we have the following different pages involved in user settings in some way or another (its a copy of this list of user_superdoc's at the time of posting)

The general plan is to redistribute User Settings across these other nodes, possibly renaming some of them if we feel its necessary. Node Display Settings and Signature Settings are the one ive put the most work into so far, but even there im not convinced im grouping things correctly. Display Settings is an earlier attempt that as far as I know is unused, and i was stupidly unaware of when I created Node Display Settings. Theme Settings seems to me to overlap with the idea of Node Display Settings and Display Settings. Timezone Settings, Personal Nodelet Settings, and Nodelet Settings all seem stable to me, although i think some of User Settings could be migrated to Nodelet Settings.

Anyway, the point here is that its not clear (to me at least) how we should group the settings as pages. A kick the conversation off kind of proposal might be:

Signature Settings

All the stuff related to how the users nodes look when they are intially created. Maybe should be renamed to be more general but i have no idea what.

Section Settings

All the stuff related to sections. Things like how many per section, FP stuff, count styles etc.

Display Settings

All the stuff related to how the user sees the site in terms of style and presentation. The CSS and theme stuff goes here as do HTML filtering and tag parsing rules (more or less what Node Display Settings is)

Nodelet Settings

Pretty well everything related to nodelets, with Personal Nodelet Settings and a hypothetical Free Nodelet Settings excluded as special standalone cases.

User Settings

Generic user settings that dont nicely fall into the other buckets. I imagine that the pmdev related stuff would show up here and maybe a few of the other special settings like node filtering and stuff like that.

Anyway, thats just to start the discussion off... :-)