Thalassa CMS

Despite less than a month passed, it's time to announce another “major” release, 0.3.00, which is now available for downloading. This time, the list of changes since the previous version is relatively long.

There are three visible changes in functioning of the CGI program, and each of those actually requires patching configuration files on existing sites:

1. it is now possible to preview a new comment before actually posting it (as of now, this functionality is only available for new comments; it is assumed that, if the user has the right to edit a comment, the need for the preview is not that strong: it is possible just to edit the comment one more time);
2. a single-use password is now required in order to request changing the user's email; this is done to prevent taking over a user's account in case someone managed to take over a single working session (which is possible to some extent when unencrypted HTTP is used);
3. one has to confirm cancellation of an email changing request by typing the word really into the confirmation input field.

Besides that:

• the new macro named %[lsort:] added, which allows (to some extent) to sort strings; actually, I'd recomment to avoid this macro as long as possible, despite it works relatively fast;
• there's now the %[sess:ifcanchangemail:] macro function; I needed it to improve functioning of the email change request form;
• functioning of the %[lindex] macro changed a bit:
  • the list can now be tokenized using Newline chars (either with or without trimming leading/trailing whitespace for each of the elements);
  • working in the mode with an escape char, when in the template argument the macro encounters the escape char followed by anything else than a digit, it doesn't keep the escape char itself, only the char that follows it (thus the escape char itself can now be inserted in the result by simply doubling it);
• fixed buggy behaviour of the subject parameter in the [servicemail] section, which accidentally didn't get through the macroprocessor (now it does);
• fixed parent comment links for multipage plain comments;
• in the Smoky template:
  • fixed (partial) support for userpics, which simply didn't work in previous versions; to make use of it, create the directory userpic/ within your site's source tree (in the directory where thalassa.ini, config.ini and other files reside), and for each user you'd like to have a userpic for, put there a file named UUU.EXT, where UUU is the user id, and EXT may be either png, jpg or gif;
  • a new parameter, named text_email_change_cooldown, added to the [html] section in the cgitext.ini file; this means you must add it to your cgitext.ini too if you use the Smoky template, the simplest way to do so is to copy-paste the parameter and its value from the new version of the template;
  • some typos and wrong wording cases fixed.

Migration to 0.3.00

If you use the Smoky template:
• copy the contents of the base/ subdirectory from the template's new version over your site's source base/ subdirectory;
• open the file cgitext.ini in a text editor, and add the text_email_change_cooldown parameter to the [html] section (which is actualy the only section in that file, so it is hard to make a mistake; something like this will work:

  text_email_change_cooldown =
  +<p>It looks like you recenlty canceled an email change request.
  +You can only make another request in 24 hours since the previous one.
  +If for any reason you can't wait, please contact the site administration.
  +</p>
  

If you maintain a non-template site, make the following changes in your thalcgi.ini file:
• in the email change request page configuration (likely the [page /changemail] section, but your configuration may use a different path), add the passtoken input field to the main request form, like this:

     <div class="form_item">
       <label for="input_pass">Single use password:</label>
       <input type="text" name="passtoken" id="input_pass" size="24" />
     </div>
  

• within the same page's configuration, find the confirmation version of the page (the one displayed for users who are already in the process of changing the email), and in the form that cancels the request (the one that submits the yes value for the parameter named cancel_change, with either a hidden input, or a submit button configured accordingly), add a text input field named really, like this:

      <label for="input_really" style="display:inline">Confirm
            (type <em>really</em>):</label>
      <input type="text" name="really" id="input_really" size="10" />
  

• add the wrong_password parameter to your [message] section, like this:

    [message]
    wrong_password = Wrong password.
  

You might also want to add a distinct version of the mail changing request page, to be displayed to users who cancelled their requests recently and still can not make another request. If you use the selector parameter to choose the page version, which is highly likely, this is done by adding another check to your selector. Suppose you use the name request for the default version (displayed to users who can request changing their emails right now), the name confirm for the version displayed to a user who has an ongoing email changing request (this version typically consists of two forms: one to submit the confirmation code and the other to cancel the request), and the name unavail for the version displayed to anonymous users (those who didn't log in). Then, your selector likely looks like this:

  selector =
    %[sess:ifloggedin:
        %[sess:ifchangemail:
            confirm:
            request
        ]:
        unavail
    ]

(this is exactly what Smoky used until the today's update). Then, supposing the new version of the page will be identified as cooldown, replace the request word with a conditional like this: %[sess:ifcanchangemail:request:cooldown]. The whole thing will become like this:

  selector =
    %[sess:ifloggedin:
        %[sess:ifchangemail:
            confirm:
            %[sess:ifcanchangemail:request:cooldown]
        ]:
        unavail
    ]

After that, add the page version itself:

  body:cooldown = <h2>You can't request changing the email right now</h2>
    <p>It looks like you recenlty canceled an email change request.
    You can only make another request in 24 hours since the previous one.
    If for any reason you can't wait, please contact the site administration.
    </p>

Besides all that, you might also want to make use of the newly added comment preview feature. To do so, first add an alternative submit bitton to the new comment submission form (likely within the [page comment] section of your configuration); the button must send the yes value for the parameter named preview, like this:

    <button type="submit" name="preview" value="yes">Preview</button>

Make an html snippet that displays the preview, like this:

  [html]
  comment_preview = <div class="comment">
    <div class="comment_head">
      <p>From %[cmtpreview:username]
      (%[or:%[cmtpreview:user]:<em>unverified</em>])
      </p>
    </div>
    %[collapsews:<div class="comment_content">
      <h3><a href="">%[cmtpreview:title]</a></h3>
      %[cmtpreview:body]
    </div>
    </div>

(this version doesn't display userpics; see the Smoky template sources for the example that does, it is within the base/cgi_base.ini file). In the comment page's selector parameter, add checks for the preview situation using the %[cmtpreview:if:] function. For example, if you used toplevel and reptocomment to identify page versions that actually display the comment form for a top-level comment submission and for submission of a comment on a comment, respectively, then replace them within your selector with %[cmtpreview:if:preview:toplevel] and %[cmtpreview:if:preview:reptocomment]. Finally, add the page version that displays the preview. Assuming the comment form itself is defined by the theform parameter (as it is done in the Smoky template), the new page version may look like this:

  body:preview = <h2>Preview (comment is not saved yet!)</h2>
      %[html:comment_preview]
      %[page:theform]