/program/modules/althing/althing_view.php - interface to the view-part of the althing module
This file defines the interface with the althing-module for viewing content. The interface consists of this function:
This function is called from /index.php when the node to display is connected to this module.
show the form where the user/visitor can compose a new post
this routine displays the form where a registered user or an anonymous visitor can compose a new post. There is a difference between the two groups: - users cannot change their name + email; this is copied from $USER, - visitors are allowed to pick their own nicknames and email address Another difference is that only registered users (with sufficient permissions) have an additional link that leads to the file browser.
The file browser allows for inserting a full path into the message area, at the current cursor position. This way the user does not have to type the filename/path when inserting a URL or an IMG.
display the althing information and all published posts OR a single post
this is the main screen that users/visitors usually see on arrival: the header/intro/question, a list of 0,1 or more published posts, and the conclusion and the footer. There are also buttons to [Post] a message or [Harvest] exiting messages.
However, this routine also takes care of requests for a single, individual post. This post is specified via the command line parameter 'post'. If it is specified AND if it identifies a valid (published) message within this Althing that single post is displayed, together with an OK-button. This function is used to direct subscribers and moderators to a specific single message. Note that most links from the single message (parents, children and even self) bring the visitor to the whole althing, ie. they then leave the single post view. (July 2014)
show a preview of the post to the user, including references to parents etc.
the user can either submit the post or go back to edit the post
display a thank-you message and the URL of the newly added post
store the new post, add relations and send mail to moderators (and maybe subscribers too)
this routine takes care of storing the (validated) data in $data['dialogdef'] and $data['parents'] into the various tables in the database. If all goes well, we also send a mail to the moderators and, if the post was published immediately, the subscribers too. On success, the array $post is filled with the post data, including the newly assigned post_id. It is up to the caller to do something with this returned post data, e.g. display it or whatever.
Storing the data takes a few separate steps. First we need to calculate a display_id which is unique within this althing. Once we have that, we can store the actual post, which yields a fresh (unique) post_id. Subsequently we can use that post_id to store the parent-child-relations in the database.
If that all works out, we always inform the moderators and, if the post was published, also the subscribers. If the post is not visible, the subscribers will be sent a mail lateron, if and when the post is published by a moderator.
display the content of the althing linked to node $node_id
validate the data entered by the user/visitor
Other than the standard validation we check for at least 1 @-sign in the email address. (It is non-trivial to validate an email address, it may not even be possible to do it in a single regular expression. See http://stackoverflow.com/questions/201323 for more information.) Note that we only check this field if it is not viewonly. Reason: the user is not able to edit a viewonly field, so an error there would be a fatal error. We don't want that.
Also, we validate the BBCode in the message.
construct a dialog definition for the add a post form
This defines the add a post form.
get all posts for this althing into an array for easy output
this retrieves data from the database in a specific order (if necessary). via $show=0 it is possible to actually suppress the output of the redacted posts
output a single post via $theme
[ ] $author $datim (#$msgid) Subject: $subject Marbles: $marbles (reply to $msgid) In reply to: $p1 Replies: $c1, $c2, $c3 Harvests: $h1
bbcode2html(Content)
Note "In reply to: $p1" might also be 'Harvested from: $p2, $p3, $p4' depending on the post.
Note: preview mode means that the displayed post does not have links to elsewhere which would let the user leave the current page. This is handy for showing a preview of a message that is not yet posted.
Note: the parameter href (default '') is used in the single post display to make sure that the links to the "relations" (parent, children) are absolute, i.e. they link to the full althing page, including headers etc. etc. (the single post page shows only a single post, without the context of the althing).
check for user action indicating wish to add a post, reply to a post or harvest posts
this checks to see if the user has taken action to start adding a new post. This is the case if
Note: In step 3A below we identify the checked posts by looking at the $_POST[] array. This is a shortcut, because usually we first setup a dialogdef and subsequently check all the elements in the $dialogdef for their values. We now sort of trust the data in the POST-array; an ordinary user will only be able to have just the checkboxes from the overview checked, leading to an element with key 'p' followed by the post_id (in decimal). An attacker might try to fool us by crafting a post with post_id's from another althing, eg. one hidden in a protected area. We mitigate that by explicitly requiring the althing_id in the WHERE-clause we will be constructing. Another possible danger is specifying many, many, many post_id's. We will limit that via the limit of posts that can be harvested in an althing (there must be a limit, somewhere, right?).
Documentation generated on Tue, 28 Jun 2016 19:08:19 +0200 by phpDocumentor 1.4.0