One thing I've changed is in DoMaintPurgeOldRevs(). Previously we relied on stat to get the file modification time, and use that to determine when to remove the old revision based on $PurgeArchives. However, along the way it was changed to check the internal ts variable instead. This is all well and good, however, it presents a unique problem. If you have a page that has been unmodified for a year, and a spammer comes along and spams it, assuming your $PurgeArchives was set to 2 weeks, the last good copy of the page will be purged immediately, leaving only the spammed version. By checking the file modification time instead, it will guarantee that you have a previously known good copy for at least $PurgeArchives time, regardless of how old that good copy was.

-- AaronGraves Wed Jul 31 16:29:38 UTC 2013 (69.4.28.21)


Aneuch will now show you the number of comments on a discussion page in the link to the discussion page.

-- AaronGraves Wed Jul 31 17:58:39 UTC 2013 (69.4.28.21)


Link behavior was changed in the Markup() sub. Now if you create a link to a page that does not exist, the name is displayed surrounded by brackets, and there is a question mark after the name, which links to the edit command for that page (i.e. ?do=edit;page=PageName). The title element says "Create page PageName".

-- AaronGraves Thu Aug 1 15:12:51 UTC 2013 (69.4.28.21)


Categories can be implemented in a rudimentary way. The way I've done it on this site so far is to put the word "Category", followed by the category name, at the bottom of each page in that category (for example, "CategoryTest"). If you then search for "CategoryTest", you will see every page with that tag on it.

While it's not perfect, it's something that's available. Ultimately I'd like to make it better than this, similar to MediaWiki.

-- AaronGraves Thu Aug 1 15:16:08 UTC 2013 (69.4.28.21)


I updated Aneuch to use the environment variable PATH_INFO, which allows you to have URLs similar to http://www.mysite.com/aneuch.pl/HomePage. This does not require a change in the .htaccess file, however I have updated the htaccess.dist file which will be included in future tarballs.

-- AaronGraves Thu Aug 1 23:14:11 UTC 2013 (174.74.32.92)


An unfortunate bug cropped up after the switch to the PATH_INFO method. On sites where no .htaccess rules were employed (and the user relied on using aneuch.pl/PageName to access their pages) the cookie path was getting set incorrectly (basically, it was including the aneuch.pl part in the path).

This was not an immediately obvious problem, since everything functioned properly until you went to save a page. Upon the POST action, the cookie would be read incorrectly (since the path was wrong), and the edit was being rejected outright. So that was fixed today.

Also today, I implemented the TextCha feature. You set questions and their corresponding answers in your config.pl file by using the %QuestionAnswer hash. This should be an effective deterrent against automated bot spam, however it will not affect human spammers in any way. That's coming next, with BannedContent.

-- AaronGraves Mon Aug 5 02:42:21 UTC 2013 (174.74.32.92)


A lot of anti-spam work is taking place in Aneuch 0.30. Read the Discuss Spam Work page for the details.

-- AaronGraves Mon Aug 5 16:00:13 UTC 2013 (69.4.28.21)


Many API's are getting added into Aneuch 0.30, which will make it much easier to extend the functionality of the engine via plugins. I'll work on documenting all of these in the coming days.

-- AaronGraves Fri Aug 9 00:58:54 UTC 2013 (174.74.32.92)


Now that the RegSpecialPage API is in place, it would be relatively trivial to set up category pages. An idea I have right now is to introduce a new config variable, call it $CategoryPrefix, with a default value of say 'Category_'. I would then register a special page using $CategoryPrefix, like:

RegSpecialPage("$CategoryPrefix*", \&DoCategoryPage);

Sub DoCategoryPage would then have to determine all pages that belong to the category (which would then be determined by taking everything from the page name after $CategoryPrefix, so that 'Category_Trucks' would search for all pages which have a category tag of 'Trucks'). Here is the tricky part - figuring out how to properly implement the category tags. Should it be a separate field in the page data block, requiring its own textarea or input field on the edit form? Or should it be something as simple as a tag at the bottom of the page itself (like [Category Trucks] or [Category Trucks,Maintenance] for multiple categories). If it's the latter, then DoCategoryPage would have to be a search function, similar to DoSearch, looking for the category tags on the bottom of the page. If the former, we could solve the issue one of two ways:

  • Read each page, then look for the 'category:' field in the data block. If the sought category is listed, store the page in a variable to display it later.
  • When saving a page, generate an index file that contains categories and their associated pages.

The second option is by far the fastest "search" method for a category page (after all, once the page database gets to a few thousand pages, searching each one would become a resource-intensive task) but potentially the most error-prone (think clobbering the category index file while multiple users are updating pages all at once).

This will definitely take some thought.

-- AaronGraves Fri Aug 9 17:35:21 UTC 2013 (69.4.28.21)


Come to think of it, the same can be said for document templates. Though I suppose if it took a couple of seconds for the edit form to display because Aneuch was searching each file in the page database for the ones that were marked template, that wouldn't be a deal breaker. Aneuch has to be fast at displaying pages. Everything else can be a bit slower, technically.

-- AaronGraves Fri Aug 9 18:19:58 UTC 2013 (69.4.28.21)


Believe it or not, even something that should be as simple as shortcodes presents a problem. Why? Well, I'm glad you asked that.

Aneuch has a plugin interface, and as such, the creole-compatible markup engine can be replaced by any number of other engines (markdown, MediaWiki, etc). So, if the shortcodes get replaced before Markup is called, as long as the injected text is the same as the current markup engine (creole by default), all will be great. But woe to the administrator of the wiki who has replaced the default markup engine with, say, markdown, and installed a plugin that expects (and outputs) creole.

The alternative to this is to replace the shortcodes post-markup, with the understanding that all injected text must be html formatted. However, this presents the problem of not being able to take advantage of the wiki features (easy textual formatting, etc).

This is another one of those features that is going to have to be thought out.

-- AaronGraves Mon Aug 12 15:32:05 UTC 2013 (69.4.28.21)


I've done some preliminary work on combining shortcodes and categories. Basically, I created a shortcode that is in the format [category:category list]. The shortcode was defined as 'category:.*'. Anything that .* matched was passed along to the subroutine that was called by the shortcode.

Next I would have to register a special page that matched a variable, say $CategoryPrefix, which would likely be 'Category_' by default. So a category page for the "trucks" category, as an example, would be nammed "Category_Trucks". Then I would need to write the subroutine which would be executed by the RegSpecialPage function. I've been toying with ideas on how to search the pages based on the previously mentioned shortcode to gather the categories.

-- AaronGraves Mon Aug 12 19:44:10 UTC 2013 (69.4.28.21)


Tonight I implemented the preview feature for discussion page comments. It works pretty well.

-- AaronGraves Thu Aug 15 00:35:24 UTC 2013 (174.74.32.92)


I have made strides in the areas of Flexible Data Structure and Templates by introducing the WriteDB and ReadDB functions.

Templates will be stored in a DB file, similar to the Page file, but the prefix will be the template name, and everything else will be the template content.

I still haven't worked out how to save a template yet. Perhaps it's a matter of a simple check box on the edit screen, but then that wouldn't make much sense, since it would have the name of the page you're trying to edit. Maybe the introduction of an administrative menu option? However that would mean that regular users of the wiki wouldn't be able to create templates...

More thought is needed. However, [WritePage?], [AppendPage?], and GetPage all call the WriteDB and ReadDB functions.

-- AaronGraves Wed Aug 28 20:09:02 UTC 2013 (69.4.28.21)


I have added another value to $SiteMode. The number is 3, and it essentially requires authentication to do anything on the site (fortress mode).

-- AaronGraves Fri Feb 14 03:24:57 UTC 2014 (68.106.213.102)


Name:
Message:

Styling
**bold**, //italic//, __underline__, --strikethrough--, `teletype`
Headers
= Level 1 =, == Level 2 ==, === Level 3 ===, ==== Level 4 ====, ===== Level 5 ===== (ending ='s optional)
Lists
* Unordered List, # Ordered List, ** Level 2 unordered, ### Level 3 ordered (up to 5 levels, NO SPACES IN FRONT)
Links
[[Page]], [[Page|description]], [[http://link]], [[http://link|description]]
Images
{{image.jpg}}, {{right:image.jpg}} (right aligned), [[link|{{image.jpg}}]] (image linked to link), {{image.jpg|alt text}}
Extras
---- (horizonal rule), ~~~~ (signature)