Thalassa CMS

Re: Pageset

It's not intended to work the way you expect. Every item of a page set is intended to be a page. Generally, a page (that belongs to a set) has a single source file; e.g., if the item id is foobar, then the source is either text file named foobar, or foobar/content.txt. Depending on the configuration, either foobar.html, or foobar/index.html is generated. If there are multipage flat comments, additional html files may be generated, like foobar_2.html or foobar/page2.html (particular names are ajustable within the configiration file), but that's all, and even in this case the only source file analyzed for the page generation is that foobar/contents.txt (or just foobar if there's no directory).

Files with names starting with _, as well as hidden files (names starting with .) are ignored within the page set item's source directory, and all files that are not ignored and are not content.txt, are simply copied (strictly speaking, published) to the destination. The intended use for them is images accompanying the page.

Re: Email-based reply notifications

Thank you for the suggestion. Unfortunately, as of now, I've got a lot of higher-priority TODO items. But the suggestion really sounds good, so maybe I'll return to it one day.

Re: login security

The cookie changes on every request to the CGI, so technically it is possible to take over a single session. To do so, the attacker must sniff cookies until the user goes idle, and then, yes, it will be possible to "continue" the session pretending to be that user. In case the user resumes the activity (with the cookie s/he still has), the session will immediately become invalid.

The possibility to take over a single idle session (without the possibility to take over the account) is, well, a bad thing, but not that horrible. Actually, it is insufficiently horrible to make me use https, but please note you can use https on your Thalassa-based site if you want, as Thalassa doesn't prevent this in any way.

Re: Thalassa as imageboard

Unfortunately, I don't think that the present version of Thalassa fits this task, as it is incapable of two important things:

1. it doesn't support file uploading, including images;
2. it can not create new pages on its own, only new comments; pages can only be created by either adding new files or editing configuration files, both manually, not via the web-based interface.

I plan to add support for both things, but I can't take any obligations on terms and deadlines.

As of your concerns, well, this page http://www.stolyarov.info/thalcgi.cgi/moderation/gb/6 (it's in Russian, sorry) contains 1200+ comments, and I see no performance-related issues. Also Thalassa supports plain comments, like here: http://infoviolence.org/ru/guestbook.html, for them it is possible to specify how many comments to place on a single page, and the generator automatically adds more pages (on the page pointed to here, the limit is 50 and there's one additional page, as of now). This functionality is not available for tree-like comments, because I don't see any consistent way to split a tree. Well, there's some approach to it at LiveJournal, but pages are generated dynamically there, AND there's one more thing: if one of the trees on a page grows large enough, other comments can move to different pages, thus making references to particular comments mutable (unstable).

It may be possible to add more styles for rendering comments, e.g., only show top-level comments on the head page (possibly splitting them too, as necessary), and making a separate web page for every discussion (that is, for all comments that respond to a given top-level comment). See the forumgen.[ch]pp module, the plain comments are implemented by the PlainForumGenerator class, and the tree is implemented by SingleTreeForumGenerator.

If you decide to code something on your own, please be sure to consult what I have at the developer documentation section, specially C++ subset restrictions and the list of banned techniques.

Re: How I can give admin to me?

Let me cite the README file which is found in $thalassa/examples/templ_smoky:

To grant a user one of the roles mentioned above, go to your CGI user db
directory (the one specified as [options cgi]/userdbdir in your
config.ini), change to the ``_users/NNNN'' subdirectory (where NNNN is the
login name of the user), open the file named ``_data'' in your preferred
text editor and a line like

   roles = admin

Re: Does deployed cms use upstream?

It's exactly the same version, actually I've got a clone of my working git repo on the hosting machine, so it's kinda continuous integration.

But yes, these two sites don't use the Smoky template, exactly the opposite is true — the template was made using fragments of those sites.

As of this site (I mean, thalassa.croco.net), it is even made with Smoky. I use the site to convince myself Smoky is working.

Why did you suspect I have different versions of Thalassa? The two sites are simple enough to be generated with the published Thalassa version.

Re: admin in templ_smoky have got no access to moderation

I can't reproduce it, sorry. This site (thalassa.croco.net) is made with Smoky, my user account (admin) has only one role (yes, "admin") specified in its _data file, and I'm perfectly able to perform moderation.

Please try this:

• go to the main page of the site;
• check whether the username, shown with green-on-black in the upper-right corner of the screen, is what you expect;
• click on that username, it will bring you to the page with the session's details, including the current active roles (for me it shows Your role list: admin auth all;
• check if there's the admin role in the list and if there's a phrase "You are one of the moderators."

Re: not provided ytid.ini and ytid.css in a source tarball

You're right, thank you for reporting this. Just a moment...

upd: 0.1.21 uploaded, the files are there

Re: very simple simple simple generate html pages?

There are two ways of doing so with the Thalassa CMS. One is to use a list with item pages; you define the page template by the itempage_template parameter within the [list whatever] section of your configuration, set a certain ini section group as the source for your list, and use sections of that group to customize every page, like

  [list mypages]
  source = ini xpage
  itempage_template = your page template here

  ...

  [xpage first]
  ...

  [xpage second]
  ...

For a working example to start, please see the "crocodiles" example available at the download page; the [list croco] is built this way, using sections like [crocodile gharial], [crocodile saltwater] etc. to define particular pages.

The other way is to use a page set. In this case you specify the template in your ini file, and make a headed text file for every page. Again, see the "crocodiles" example, it contains a pageset named "articles"; take a look at the [pageset articles] in the configuration file, and the files in the articles/ subdirectory of the archive.

If you provide some details for the task you have, I'll perhaps be able to give you more specific recommendations.

UPD: in the first version of this comment, the word page was used for the section group name that defines pages for the list; that won't work, as Thalassa itself uses the [page ] section group. So, I replaced the word with xpage.

Re: Bottomnavbar arrows

You may be right, I'll think on this.

UPD: fixed; thanks for reporting this.

Re: 500 Check userdata directory

Userdata directory is explained here, and there's a parameter named userdata_dir in the global configuration section of the CGI program.

In your particular setup, I'd recommend you to create a directory like /var/www/mysite_data and make sure that in the thalcgi.ini, in the [global] section, the parameter looks like

userdata_dir = ../mysite_data

In case you use the Smoky template, the thalcgi.ini is generated by the template; in the config.ini file, in the section [options cgi] set the parameter userdbdir like this:

userdbdir = ../mysite_data

and in the section [options dir] section, set something like

spool = ../mysite_data/_spool

BTW, thank you for reporting this, as now I see these two parameters (instead of just one) may be confusing, so I'll consider to remove that "spool" parameter in future versions.

And one more thing: why don't you just specify your /var/www/html as the target directory?

Re: Possible bug was found

Fixed. Thanks!

Re: stack of tech

There's a lot of Javascript right at the main page, and there's no reason to look into it any further. If you consider it acceptable to send turing-complete code to your visitor's browser, we've got nothing to discuss at all.

Anyway, you must be mad to think such a bastard that needs SQL, is written in an interpreted language and even utilizes parallel programming is smth. I can like.

Actually, I believe such "technologies" must be criminalized, with significant money penalties for distributing software written in interpreted languages, and with several years in prison for making JS-containing sites publicly available. Actually, imprisoning should be in effect for creating any situation when a end-user's computer downloads any program code and executes it, unless explicitly ordered to do so by the user (with lots of warnings). Besides the so-called "web-applications", this antipattern covers automatic software updates, various plugins and a lot of other bad things.

UPD: having read your next comment, I confirm that we've got nothing to discuss. I generally don't waste my time on jerks who advocate usage of client-side execution in any way. No further comments from your part will ever pass premoderation on any of my sites.

Re: Why don't you like nginx?

First of all, why do you assume that I dislike it? That's not true, the truth is that I never tried it and I'm not going to give it a single try in any foreseeable future. I got used to Apache in 1997 when nginx didn't exist; Apache serves my needs as an HTTP server. At hands, I've got no problem, which nginx can be a solution for. Why the fuck would I spend (well, waste) my time learning how to deal with nginx? My time is too precious to waste it trying every new piece of software just because it becomes available.

What I know for sure is that it doesn't support the CGI interface directly, so it is likely to cause problems for me rather than to solve any of problems I really have.

Re: Re: set up thalassa with Apache 2

> How do I configure suexec to use testcms to throw files into target

Actually, I don't understand this question. Suexec does not throw any files anywhere.

Perhaps it is possible to create a kind of step-by-step instruction how to configure the apache+suexec+thalassa bundle, but it's definitely not for a small comment, it's a task for a day or so. As of now, may be I can provide some help if you tell what actually doesn't work, and how does that look.

Thanks!

Thank you for catching this. It's unlikely I'd ever manage to catch this flaw on my own because the whole thing with all the libs builds in less than 10 seconds so it's very unlikely I'd ever run make with -j :-)

The right fix here is different though. It is a single line

captcha.o: captcha.c captcha.h lodepng.h _letters.c

added anywhere in the Makefile, and yes, only the dep line without the command. Well, heh, the only reason it wasn't there already is that the lib/captcha directory is nearly the only one with a code written by someone else, not me. Oh, okay, md5 is also someone else's, but, well, it wasn't made for this project (unlike the captcha, which was intended for Thalassa).

Re: CGI settings

The thalcgi.cgi program only uses one configuration file, named thalcgi.ini (NOT config.ini, which I don't know where you got from).

However, if you try thalcgi.cgi and get the 404, the problem is not with the config. In case thalcgi.cgi runs but fails to read its config file, it generates a built-in error page. So the problem is with your HTTP server configuration.

Try a script like this:

#!/bin/sh

echo "Content-type: text/html"
echo ""
echo "<h1>it works</h1>"

Place it in your site's directory, make sure you made it executable, and then hack your server's configuration until at the URL like http://your-site-domain-name.com/test.cgi you see the phrase "it works".

UPD: You didn't indicate it, but after some thoughts I suspect you're using the Smoky template, which really has a file named config.ini. This may make the situation more complicated, because thalcgi.cgi has its own 404 page, which it displays in case the requested path (these path tokens after thalcgi.cgi/) is either not configured, or the path predicate returns no for the respective page. So, it is necessary to have more information here, e.g., does thalcgi.cgi work properly for displaying the session status, the contact form and other things not related to comments.

Re: Does not work on FreeBSD

Thank you for reporting this. It is more or less obvious why it doesn't compile and how to fix the problem; however, unfortunately I've got no access to a working FreeBSD now, so I'll be unable to check if the result is okay.

Anyway, I'll do my best to fix this in the next source tarball to be published.

Re: Does not work on FreeBSD

Hello, i had same problem, but it is easy to repair. In file cmd.cpp just change all existing signalhandler_t to sig_t and setpgrp() to setpgrp(0, 0) and all will be work fine. look on man signal

Re: Interesting project!

I myself was a bit surprised by how fast it works, specially taking into account that I didn't do any intentional optimizations for speed. However, surprisingly enough, it wasn't my goal to create another static HTML generator; for me it has any value only together with the CGI program which provides user comments feature.

Anyway, if you give Thalassa a try in one of your projects, any feedback is welcome.

As of the logo, you're right, I'll reduce it.

Re: Files suffixes

> XHTML 1.0 Strict?

It's not strict, it's "Transitional", solely because I need the iframe tag which is prohibited in the "Strict": in the head of the main page, that small black window with green chars is generated by the CGI, while all the page is static. Anyway, no part of generated content is hardcoded into the binaries, it all comes from the configuration, so it's possible to switch to the "Strict" version just by editing the ini files.

> Why .html, not .xhtml

The exact names of the files being generated are configured, too, so this is not a problem for Thalassa itself. Well, honestly speaking, in the present version of the Smoky template, the respective part of the configuration is within the ``base/'' subdirectory, which is not intended as user-editable, but nonetheless it can be edited. Actually, if this is important for you, I can add an option for the file extension in one of the upcoming versions.

However, as for the parser version: for the ``text/html'' mime type, as far as I understand the logic, the actual markup version is to be determined by the file's content, in which the exact format is specified, and I think this is generally better; furthermore, I doubt it is really correct to use ``application/*'' for anything intended as a human-readable text (to be rendered by the browser, not by an external application), despite servers, including the Apache I use, really emit that ``application/xhtml+xml'' for .xhtml files.

Re: Modules

Something like that is possible in future, but decisions of this sort should be balanced.

As of now, Thalassa consists of two statically-built binaries (the static content generator and the CGI), and the CGI even doesn't support loading multiple configuration files (the generator does, and in the Smoky template the configuration file for the CGI is actually composed by the generator). This minimalistic architecture has its own advantages, at least it is self-containing (hence minimal effort from the sysadmins) and quick.

Can you, maybe, give some examples of functionality you'd like to have implemented as modules?

As far as I can imagine, some useful things can be implemented simply as additional configuration sections, and some can be additional (optional) CGI programs, possibly using the same session data (the cookie and all related stuff) and user accounts; such CGIs can be thought of as plugins. Should we ever need more built-in macros in the generator, it is better to implement them within the existing program, may be as optional modules added at the compile time.

What I'd like to avoid is an infrastructure for real pluggable modules.

Re: What about WAP version support?

There's no need to add anything like that to Thalassa itself, because actually Thalassa is a (domain-specific) macroprocessor, so it is able to generate whatever texts you want. For example, there's RSS feed on this site, despite there's no special support for RSS in Thalassa, it is solely a question of writing proper configuration files.

As of adding WAP, e.g., to the Smoky template, it might be a good idea, but personally I'm not familiar with WAP and right now I've got higher-priority tasks. Maybe later.