LoginRegisterCommercial SupportContact Us

Documentation > General Documentation > Webtop > Zine Module

Zine Module

posted on 10:06 AM, October 6, 2009

Zine Module Control Panel

About the Zine Module

The Zine Module is an application for creating and managing (e-)Zines. A Zine is simply a collection of articles, and an article is a piece of text with a certain set of attributes, including at the very least, an author and a title. For example:

  • a magazine article
  • a book chapter
  • a comment or letter from a reader
  • and so on...

There are four fundamental classes of article:

  1. zine - an article collection that follows a consistent set of indexing rules
  2. article - a normal article, which is associated with a zine
  3. comment - a note or comment added by a reader, and is associated with an article (or sometimes directly with a zine, such as a forum)
  4. attachment - a photo, figure or other attachment that is associated with a zine, article, or comment.

In a very general sense, all of these are treated as "articles" at a low level.

Types of Zines

Before you can create articles, you must have some zines to place them in. The zine type determines the basic rules of zine behaviour, such as how indexes are displayed, whether you can add comments, and so on.

This is a generic e-zine. It accepts articles from a variety of authors, and displays them most recent first. Older articles are expired into the archives.
Books are assumed to collect a series of articles from a single author. They are presented in a specific order (eg. as a series of chapters), and do not expire.
Blogs accept articles from a single author, much like a magazine column. They are presented most recent first, and eventually expire into the archives. They usually accept comments from readers.
PhotoBlogs are similar to regular blogs, but they highlight the picture, rather than the text of the article.
Forums dispense with regular articles, and cut straight to comments from site readers.
PhotoForums are like PhotoBlogs, except that any site reader may post a photo, and receive comments.
Wikis are cross-linked collections of articles, which any site reader may add to.

Managing Zines

Managing your zines typically consists of adding articles, deleting or disabling comments, and occasionally adding or reconfiguring your zines. There are two ways to access your zines as an administrator:

  1. Go to the Zine icon in the ExSite web top. This gives you access to all administration and configuration functions.
  2. View a dynamic web page that is displaying the zine you want to work on. (If the page is normally published statically, you should preview the page in your favourite CMS plug-in.) This lets you add new articles, if the policy allows posts from somewhere other than the administrator control panel.

Administration functions are described below. Two icons are shown, a simple GIF and a full-colour PNG. Which one you see will depend on system configuration:

Add a new article.

Edit an existing article. This includes changing the article status so that it is not displayed (eg. moderation).

Reconfigure an article. This includes changing some of the special configuration rules noted above.

Delete an article.

Note that you will have these options for every zine, article, and comment in the system. To add a new article to a zine, be sure to click the icon under the zine; if you click the icon under an existing article, you will be creating a new article nested underneath the existing article (ie. a subindex).

You may also see the the public/user-level functions, namely:

Add a comment.

Reply to another comment.

Enter or exit the archives.

Get an RSS feed of this zine.

Users who have recently added a comment may also have the option to edit their comments. The option to edit comments only exists for a few minutes before the comment is frozen; this is so that comments do not get out of sync with their replies.


Editing Articles

When creating, editing, and configuring articles, you will be able to enter data for many of the following fields. (Which fields you see will depend on the zine or article type.)

Author The author of an article, if different from the owner.
Name A simple browser-friendly version of the article title, used in URLs. This field will be set automatically if it is left blank, but you can set it manually if you want more control.
Title The full, human-friendly title of the zine or article. For comments, this is the subject line.
Subtitle Optional subtitle, for articles that require more complicated title structures.
Summary An optional outline or abstract for the article. A summary will be automatically generated if you do not provide one. (The automatic summary consists of the first 50 words or so of the article.)
Article The full body of the article or comment. For normal articles and zines, it will default to a rich-text HTML editor, but can be switched to a plain-text input box. For comments, it will default to a plain text input box.
Content-type Sets whether to treat the article contents as HTML (no further markup required) or text (will require some extra markup for display in browsers).
Footnotes Optional; displayed at the bottom of the article. Can be used for footnotes, attributions, copyright notices, etc.
Sortkey For sorted indexes, the articles will be sorted based on this sortkey.
Picture An optional image can be uploaded, and will be displayed at the top of the article (float right, if there appears to be room). This is also the primary content of photoblogs and photoforums.
Thumbnail Thumbnailed version of the picture, above. The thumbnail is usually generated automatically.
Caption A caption for the picture.
Site For zines, this sets which site owns (and therefore may display) the zine. If no site is set, it may be displayed by all sites.
Owner This sets which user owns the zine and may access the administration functions. If not set, the site adminsitrator is the owner.

Note that you will see many of these fields for the zine itself, as well as for the articles that go into the zine. In the case of the zine itself, the values will be used to format a "preamble" for the zine index. For example, you could have an e-zine with the following values:

Title News
Name News
Footnotes All news stories are © 2007 by Acme Corp.

This information would be placed at the head of all indexes into this zine, as if it was an article without any body text. For example:


All news stories are © 2007 by Acme Corp.

News Article #1
This is the article summary. This is the article summary. This is the article summary.

News Article #2
This is the article summary. This is the article summary. This is the article summary.


Zine Configuration

The different types of zines differ only in their basic rules, which determine how they accept, present, and index their articles and comments. The rules are:

whatami what this item is called any string
allow whether this class can be posted directly under a zine 0, 1
nest whether this class can be posted under another item of the same class 0, 1
policy who may post items of this class forbidden, admin, owner, member, public
indexlimit* maximum number of items to list in an index any integer, or -1 for unlimited
indexmin minimum number of items to list in an index any integer
indexformat* how to present each item in an index title, basic, summary, full
indextype* how to structure the index basic, list, numbered, paged, gallery, grid, deep, threaded, semi-threaded, wiki, archive
indexsort how to order the items in an index sorted, date, reverse-date, flip-flop, reverse-flip-flop
indexage* maximum age (in days) of items in an index, before expiring them any integer, or -1 for no limit
attachments how many attachments to prompt for when posting items of this class any integer
status default status of newly posted items active, pending
showdate whether to display the posting date 0, 1
showauthor whether to display the author 0, 1
fields which record fields to prompt for list of column names
required which record fields must be filled out list of column names

Rules can be set in the following ways:

Zine & Article Rules

Some rules (marked with asterisks, above) can be set in the records of individuals articles. They may be ignored if set in regular articles or comments, but for zines, they should take effect fairly reliably.

Configuration File Rules

Rules can be set in the Zine configuration file, using one of these syntaxes:

# CLASS.RULE, for example:
article.policy = admin
# ZINE.CLASS.RULE, for example:
blog.article.policy = owner
wiki.article.policy = member

These configurations say that only administrators can post articles. However, in blogs, the blog owner may post articles, and in wikis, any member may post articles.


comment.policy = fobidden
blog.comment.policy = public
forum.comment.policy = member

This says that in general, comments may not be posted. However, the public may comment in blogs only, and site members may also comment in the forums.

Default Rules

The default rules are set out in Modules::Zine::Config. You only need to specify differences from these rules in your local configuration files.

Resolving Rules

When determining which rule to use in a specific case, the Zine Machine looks for a defined rule in the following order:

  1. In the current article.
  2. In the reference zine, if the reference zine allows articles of the current class. For example, blogs allow articles, but not comments to be posted directly to the blog (comments are only posted to individual articles). Therefore we will check the reference zine for an indexing rule for articles, but not for comments. Forums, on the other hand, allow comments to be posted directly. Therefore we do check the reference forum for rules on formatting comments.
  3. In the zinetype-specific configuration setting, eg. blog.comment.policy.
  4. In the generic configuration setting, eg. comment.policy.
  5. In Modules::Zine::Config.

Comment Management

Comments can be posted by website readers under articles or forums, if the zine configuration allows it.


Comment Policies - Enabling/Disabling Comments

Every zine and/or article has a comment policy which is one of:

  • forbidden: no one may post comments here
  • public: anyone may post comments
  • members: authenticated members of the site may post comments

The comment policy is taken from (in order): the article comment policy (if set), the reference zine's comment policy (if set), the default policy for the zine type (if set), and lastly the default global comment policy. The last two are set in the Zine configuration file; the others are set on the configuration panel for a particular zine/article.

To disable commenting under a particular zine or article, set the comment policy on that one article to forbidden. Other zines and articles will not be affected.


Public Comments

Public comments can be posted by anyone at any time. They can enter any name in to the "From" field. The following configuration parameters control how public comments are handled:

  • allow_anonymous: if true, accept comments with no "From" setting; otherwise users must enter a name.
  • anonymous_name: if no "From" setting, use this name (default is "Anonymous").
  • shrink_anonymous_comments: if true, then public comments are shrunk down to a link. Readers must click through to read them.
  • mark_unauthenticated_comments: if true, then public comments are marked with extra text to mark them as unauthenticated.
  • unauthenticated_comment_mark: the text used to mark unauthenticated authors (default is '(?)')
  • use_captcha: unauthenticated commenters must solve a captcha to post. This reduces automatic spamming abuse.

Member Comments

To post a comment in a zine or article with a "member" comment policy, the user must be logged in to the website. Their name is automatically filled in to the comment form, and there is no need to solve a captcha.

The configuration setting editable_author can be set to true to allow members to change the From field of their post. The comment is still connected to their member record, even if they change the visible author settting.

The configuration setting withhold_name causes a blanked From field to display as "(name withheld)". Otherwise an empty From field is simply treated as no data, and the user name or login ID will be used instead.

Non-members may still see links/buttons to post comments, but will receive an error message if they attempt to use them.


Comment Indexes

Comments can be indexed in all the same ways that articles can be indexed. Some index formats are particularly suited to comments:

Index TypeDescription
Deep All comments are displayed in a flat index.
Threaded All comments displayed, indented under their parent comments.
Semi-threaded The opening comment of each thread is summarized in the main index. Following this comment takes you to a fully-threaded display of that thread.
Exploding Like Threaded, but the comment levels can be expanded and collapsed dynamically by clicking on buttons.

Comment index types are set in the configuration file, using the following parameters:

  • comment.indextype: system-wide default
  • TYPE.comment.indextype: default for a specific zine type

For forums only, you can also set the index type for a particular forum in the zine configuration screen. (For other zine types, this setting affects article indexes only.)



Using the indexing rules for zines, you can devise a variety of formats for your comment indexes. Here are some examples to help you understand how to do this:

Show full comments under blog articles:
blog.comment.indexformat = full
Show links to comments under blog articles:
blog.comment.indexformat = brief
Sequential index of blog comments:
blog.comment.indextype = basic
blog.comment.indexsort = date
Numbered blog comments:
blog.comment.indextype = numbered
blog.comment.indexsort = date
Fully threaded forum, with most recent threads on top
forum.comment.indextype = threaded
forum.comment.indexsort = reverse-date
Fully threaded blog discussions (a la Slashdot)
e-zine.comment.indextype = threaded
e-zine.comment.indexsort = date
Semi-threaded forum with tabular presentation (a la PHPBB)
forum.comment.indextype = semi-threaded

Comment Input & Output

The following configuration settings affect the entry of comments:

  • editable_author - members can change the From field, if true. This only affects the displayed "From" value. Comments are still tied to the member's user record.
  • quote_parent - on replies, the parent comment will automatically be quoted, using conventional plain-text email quoting methods.
  • default_subject - on top-level comments, a subject field will automatically be defined, if true.
  • edit_my_comment_timeout - if set to a positive integer, a user will have that many seconds after posting a comment to re-edit it. This is meant for proof-reading and corrections, not for changing the meaning of your message after others have already read and replied to it, so it is best to keep the time limit to a few minutes (eg. 180 seconds).

Comments are entered in plain-text format by default.

Smileys (emoticons) may be entered in their conventional text forms, eg. :-).

Limited HTML is accepted, but structural HTML (eg. DIVs and TABLE markup) will not be.


Display of Comments

The following configuration settings affect the display of comments:

  • remove_quote_char - the ">" prefix on each quoted line will be removed, if this is set on. This can be handy if you use CSS to style the quoted section and want a cleaner display of the text. Note that only the first level of quoting is removed, so if a quote is quoted, the second (and higher) levels of quote characters will remain in the text.
  • body_strut_size - if set to a positive integer value, the comment body will include a "strut" of that many pixels height. This effectively sets a minimum height of the body region of the content, which can be useful in pseudo-table layouts where the poster info is shown in a cell to the left of the comment itself. Heights of 50-100 suffice in most cases.
  • emoticons - if set on, text emoticons will be replaced with graphical equivalents, as shown below.

Line breaks in the comment are preserved by the addition of

Quoted sections are wrapped in


tags of class "ZineQuote", allowing special CSS rules to be applied to quotes.



By default comments go live immediately. (That is, their default status is "active".) If inappropriate comments are entered by site readers, the webmaster can manually delete or edit the comments after the fact.

To vet all comments before they go live, comment moderation must be enabled. To do this, change the default status of a comment to some other value, as follows:

# by default, all new comments are pending moderation
comment.status = pending
# new forum comments are pre-approved, however
forum.comment.status = active

New comments will be created with the default status. If the status is not "active", the comments will not be visible to the public. Furthermore, as soon as an non-active comment is entered into the the system, the moderator will be notified with an email message. This message includes links to accept or reject the comment.

When viewing comments in an administrator view (eg. the Zine control panel), all articles and comments are flagged with a graphical icon indicating their status. Inactive comments include extra tools to accept or reject them.

In addition to using the moderation links/tools, you can always change the status of particular articles/comments using the configuration page.


Layout & CSS

Zine articles/comments are all formatted primarily using DIVs for layout and markup. Some CSS is necessary to "dress up" the content.

The Basic Zine CSS structure is as follows:

Zine                             Wraps all Zine output
    Zine[TYPE]*                  Wraps a single article
        ZineHeader		 Contains the title, subtitle, and abstract
	ZineAboutBody		 Wraps the About and Body sections
	    ZineAbout		 Contains author info & date
	    ZineBody		 Contains the article text
	        ZineImage	 Contains inlined image, if any
	        ZineQuote	 Contains any quoted elements in comments
		ZineAttachment	 Contains any attachments
	ZineFooter		 Contains footnotes, etc. 

* [TYPE] = Article | Comment

Other Groupings/Wrappers include:

ZineIndex                        Wraps lists of articles
ZineItem                         Wraps a single entry in an index
ZineTitle                        Contains the article title
ZineAuthor                       Contains the author attribution
ZineDate                         Contains the posting date

The ZineAboutBody wrapper is useful if you want to display comments in a two-column format, as is popular in some forums. The CSS technique for doing this is illustrated below. Otherwise it can be ignored.

Note all article classes have the same basic structure. However, each article type has its own unique wrapper, which you can use to differentiate between them stylistically. The sample CSS and HTML in the example below shows how this can be done.

View the source of this page to see the actual HTML structure. The stylesheet to achieve these effects can be viewed here.


Floating Images

Pictures are automatically inserted at the top of the article. Attachments are automatically shown in a thumbnail gallery at the end of the article.

If the picture width is lower than img_max_wrap_size, and the article body is longer than body_min_wrap_size, then the picture and caption will be wrapped in the following HTML:

This code is only added if the image is small and the article is large, because those are good conditions for wrapping the article body around the image. The following CSS will accomplish this (also illustrated in the example below):

div.ZinePicture { float:right; }

Attachment thumbnails will tend to stack vertically on the page. To have them line up left-to-right, use the following CSS:

div.ZineAttachment {
    height:125px;  /* enough to contain the thumb and caption */
div.ZineAttachment table {
    float:left; padding-right:10px;

Pseudo-Table Layouts

The basic layout uses divs, which means elements will stack vertically by default. If you want a side-by-side layout, with different elements positioned beside each other as if in table columns, you can use CSS to reposition certain elements.

The most common application is for structuring comments in boxes with meta-information about the post in the left column, and the comment body in the right column, like so:

about info comment body

To accomplish this layout, you need the following minimum CSS to get the two-column layout:

.ZineComment .ZineAbout {
.ZineComment .ZineBody {

You can get the same effect with regular articles by replacing "ZineComment" with "ZineArticle", or by removing ".ZineComment" altogether to have it apply to both types.

Some additional padding will also be needed to make things attractively spaced. Multi-column CSS layouts do not handle rules and borders very well, so if using borders, you will have to simulate the rules and backgrounds using a background image. All of this is done in the example below, so use the associated stylesheet and HTML as a guideline.

In this case, the left column is a float, and its contents may overflow the "box" containing it if the right column is unexpectedly brief. To avoid this, you can add a minimum-height strut to the comment body, by adding the following setting to your config file:

body_strut_size = 60

The size is the minimum height in pixels of the body area. Increase or decrease as necessary. Set it to 0 to eliminate the strut entirely and let the text flow where it may.



This example illustrates that even though articles and comments have essentially the same markup, you can give them markedly different presentations by making your CSS rules sensitive to their context. This uses the same CSS rules as the Zine Control Panel:

This is the article title
About, Author, Date
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
footer text and toolbars go here
This is the comment subject
About, Author, Date
quote quote quote quote quote quote quote quote quote quote quote quote quote quote quote quote quote quote quote quote quote quote quote quote
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
footer text and toolbars go here


Wikis are editable knowledge bases, that allow for easy cross-linking of articles.

Wiki Indexes display a single article with name "_start" by default. They also provide a search box to find other articles.

Wikis normally provide for regular users to add articles into the system. A popular example is Wikipedia, which lets any user edit any article. The ZineMachine wikis work slightly differently. Any user may only edit their own articles, unless they are the administrator. However, any user may add their own articles under the same keywords.

Therefore, if you need to correct or expand upon an article written by another user, simply create your own article, and provide your clarifications there. Both articles are shown when that keyword is viewed. Alternatively, you can comment on the orignal article, in the usual way.



To cross-link to another article in the wiki, enclose your keyword in double-parentheses, like this:

The ZineMachine allows you to create and manage blogs.

The ZineMachine will automatically convert this to a link to find articles under that keyword. It searches the article titles for matching keywords, and shows all articles found.

If no articles are found under that keyword, you can use the new article button to create one.

To cross-link to a keyword, but use different text in the link, specify the anchor text after the keyword, like this:

The ZineMachine allows you to create and manage guest columns.

Zine Data Structure

E-Zines are comprised of articles organized into hierarchical trees. Each article has a class, which determines where in the tree it is expected to appear. Each article also has a type, which is more specific than the class for zines. (For articles, comments, and attachments, the type and class are equivalent.) The zine type determines general formatting and indexing rules for associated articles. The various types are:

e-zine zine Holds articles by various authors, which eventually expire into the archives as they are replaced by newer articles.
book zine Holds an ordered set of articles that collectively comprise a single work. Articles do not expire.
forum zine Holds ongoing commentary from the readership.
news zine Holds articles which eventually expire into the archives as they are replaced by newer articles. Authors are usually not noted.
blog zine Holds articles by a single author, which eventually expire into the archives. Analogous to a magazine column, or an online diary.
wiki zine Holds articles by various authors, which can be cross-linked, and which the readers can contribute to.
photoblog zine Similar to a blog, but emphasizes the image content over the text content.
regular article article These are the individual stories/posts that readers are consuming.
comment comment Readers can append their own thoughts to particular articles or forums.
attachment attachment These are images or other files that are connected to zines, articles, or comments.

Article Trees

The rules for how articles in the overall tree are allowed to nest under each other are:

  • zines may only nest under zines
  • regular articles may nest under zines or other regular articles
  • comments may nest under articles or comments; comments may also nest under forums
  • attachments may nest under any type

It may be possible to configure article relationships to break these rules, but in that case there is no assurance of the misconfigured articles being found and displayed by the system.

Each article has a parent article, which is the next article higher in the tree. To build a tree object from an array of articles, use this:

my $tree = new ExSite::Tree(
                            "article_id",    # primary key
			    "parent_id",     # parent key
			    @articles        # tree nodes

In principle the entire tree can be defined and constructed using only the parent reference. However, this makes for inefficient and recursive queries to retrieve the data needed to build the tree. To allow for simpler and more efficient queries, we also track each article's thread and reference.

The thread is the highest-level article of the same class. If the current article is the highest-level article of the same class, then the thread is not set (ie. it is set to 0).

The reference is used to group related articles. For comments and articles, the reference is the lowest-level article of a different class above it in the tree. A record with no reference is at the top level of the tree.

Attachments have the same thread and reference as the article they are attached to. This makes it easier to select article and their attachments together in a single query.

For example, consider a single branch of the article tree that nests as follows:

  • Zine Z1
    • Zine Z2
      • Article A1
        • Article A2
          • Comment C1
            • Comment C2
              • Comment C3
                • Attachment Att1

The following relationships hold true:

Z1 n/a n/a n/a
Z2 Z1 Z1 Z1
A1 Z2 n/a Z2
A2 A1 A1 Z2
C1 A1 n/a A2
C2 C1 C1 A2
C3 C2 C1 A2
Att1 C3 n/a A2


To build a complete index of articles and their comments under a particular zine, while ignoring all other zines, select all records whose reference points to the zine of interest:

# construct a tree of everything in Z2
my @articles = $db->fetch_match("article",{reference=>$z2});
my $tree = new ExSite::Tree("article_id","parent_id",@articles);

To fetch a list of threads (ie. top-level comments) in a forum, select all comments whose reference is the forum, and whose thread is not set:

my @articles = $db->fetch_match("article",{type=>"comment",reference=>$forum_id,thread=>0});

To fetch a complete thread from a discussion, select all articles of a given thread:

# fetches all articles under the top-level article
my @articles = $db->fetch_match("article",{type=>"comment",thread=>$thread_id});
# fetches all articles including the top-level article
my @articles = $db->fetch_match("article","type=\"comment\" and (article_id=$thread_id or thread=$thread_id");
my $tree = new ExSite::Tree("article_id","parent_id",@articles);

Developer Customization

The ZineMachine supports handlers for customizing presentation beyond what basic CSS allows for. The supported handlers are:

  • ZineAbout
  • ZineAbstract
  • ZineAttachment(@attachments)
  • ZineAuthor
  • ZineBody
  • ZineFooter
  • ZineHeader
  • ZineIndex(%opt)
  • ZinePicture($img)
  • ZineRSS
  • ZineShow
  • ZineShowArticle
  • ZineShowInfo
  • ZineShowTeaser
  • ZineShowRow($data,@columns)
  • ZineShowFull
  • ZineTopView
  • ZineThumb

If you register a handler under any of these names, that handler will be called to generate the given item of content. (For example, the "ZineAbout" handler can be used to generate the "ZineAbout" section.) If the handler returns undef, then the ZineMachine will fall back on its default rules, so your handler can run conditionally.

You can define and register your handlers in myConfig.pm. All handlers will be executed under the Zine class, as if they belonged to the Zine framework.

See the Kernel developers guide for more information on handler programming.

Example: Poster Mini-Profiles

Some forum systems like to display a mini profile of the poster next to the comment. This may include information about their membership, location, posting history, and even a small thumbnail.

The HTML structure of comments allows meta-information about the post to be placed in an "about" block, which has a CSS class of "ZineAbout". By default this block contains the author name and posting date.

To customize the contents of the about block, you can define a handler that provides the contents of this block. The handler is dynamically scoped into the Zine class, so it has access to the internals of the Zine object (the Zine::Article object, in particular) from which it was called. It returns an HTML string that is used to populate the about block.

Handlers should be registered and defined in the myConfig.pm file.



# in myConfig.pm

sub my_handlers {
    my $this = shift;

    # register our special handler

# now define our handler

sub myZineAbout {
    my $this = shift;     # $this is dynamically scoped into the Zine classes

    # get the UID of the owner of the post
    my $uid = $this->{article}{owner};

    if ($uid) {
       # ... a bunch of code here to fetch the relevant user info to display
       # ... more code to build an HTML snippet to display this info
       return $user_html;
    else {
       # no UID - likely an anonymous or public posting
       # we return undef, which will default back to the generic about block
       return undef;