25 thoughts on “Aneuch”

  1. Greetings,
    Both versions 0.10, and 0.20 should be considered unusable.
    To the point; there is an issue posted within the tracker, that is considered “low priority”.
    But the bug renders Aneuch useless.
    The bug:
    HomePage and RecentChanges, as well as anything within the top menu, have links with the following attributes:
    aneuch.plHomePage or aneuch.plRecentChanges etc… — see the problem?
    Links of this nature will ALWAYS return a 404 not found, by the server (Apache 2).
    There is no env pollution. Everything within the (servers) environment is, as expected/anticipated.
    $DataDir is a sub-dir from document root. aneuch.pl, and config.pl are in document root.
    $DataDir is the FULL path to the sub-dir.
    Please consider following up on the Bugs listed within the projects tracker, or remove the tracker completely.
    Thank you for all your time, and consideration.

    • Thank you for your comment. I was unable to duplicate that bug from the report, however given your comment here I know exactly where the problem lies. My inability to duplicate the bug stemmed from always calling aneuch.pl from a separate index.cgi script, which in connection with my .htaccess rules insured the script name was never part of the url. Thank you for clarifying exactly what the problem was, a fix should be pushed out tomorrow.

  2. Thank you for your attention to this matter.
    When might one find a “working” version? ๐Ÿ™‚

    Thanks again.

  3. Excellent, and thank you very much for taking the time to fix this so quickly!
    On another note; should Page Titles look thusly?
    aneuch.plDiscuss HomePage
    Just wondering. Seems strange.
    Perhaps a “feature” request; but wondering if there’ll be a version that doesn’t require mod_rewrite.
    Seems it’d be fairly trivial to incorporate the “logic” within config.pl — no?

    Anyway, thanks again. I really appreciate it, and all the work you’ve done. ๐Ÿ™‚

    • Hi Chris,

      Could you grab a copy of http://ajgraves.myunixhost.com/tmp/aneuch.pl and test it out, to make sure everything works?

      Note that this introduces a new configuration variable, $FancyUrls, which affects the original bug report as well as your feature request. The default setting is 1 or enable, which requires .htaccess to be configured to allow “fancy url’s”. You will have to add it to your config.pl file and set it to 0 to test the bug fix and your feature request.

      Let me know if you have any issues with this. And thanks for your kind words!

  4. Greetings Aaron, and thank you for your continued attention.
    I’m afraid I’m a bit confused. Maybe I wasn’t very concise. I checked the link you kindly provided. It appears that Aneuch now provides “Directory listings”. ๐Ÿ™‚ While that could sure come in handy for links to “downloads”, and what-not. I’m not sure where that addresses the issue, and “feature” I mentioned. Make no mistake, I think what you provided is really cool. But my issue stemmed from receiving “404 not found” because the links appearing to the browser looked as: http://mydomain/aneuch.plHomePage Now I understand that this can be circumvented via mod_rewrite. But things didn’t work out that way. .htaccess didn’t throw a “301 redirect” as intended. The other issue, is that going to: wikis/aneuch.plHomePage, shows aneuch.plHomePage as the title on the page.
    Thank you again VERY much, for all your time, and effort. I GREATLY appreciate it.
    I hope I was clearer/ more concise this time, and apologies for not having been so, in the first place. ๐Ÿ™


    • Directory listings? Now I’m confused ๐Ÿ™

      The file I linked to, did you save it over your existing ‘aneuch.pl’ on your webhost (download it from me and then upload it, overwriting your copy of aneuch.pl)? Did you add the variable $FancyUrls = 0; to your config.pl file?

      The modifications I made to it will make it so the URL, instead of being http://mydomain/aneuch.plHomePage as you report, will now show up in the correct manner as http://mydomain/aneuch.pl?HomePage (note the question mark in between the script name and the page name). I’ve tested this on a bare install of Aneuch and it works perfectly.

      Can you confirm you followed the steps outlined here?

  5. Thank you Aaron for such a fast response.
    fetch: http://ajgraves.myunixhost.com/tmp/aneuch.pl: Not Found — Was my experience.
    I presumed that any attempt to simply download it by way of browser, would result in the Perl exec’ing aneuch.pl. Leaving me with the rendered page, not the Perl script. Just checked; I got the rendered page, not the script. ๐Ÿ™
    Saved it with my Browser, as fetch(1) (I’m on BSD) returned the results I posted at the top of this reply.
    How would you suggest I download it?

    • Hmm, that’s very interesting, I’m on Bodhi Linux and used wget and it returned a 404 (but if I visited the link in the browser it executed).

      So I created a tgz: http://ajgraves.myunixhost.com/tmp/aneuch.tgz

      Try downloading that, I verified it would download.

      What BSD are you on? I used to use FreeBSD, still love it, but don’t have a spare machine to run it anymore. Hoping to get one soon.

  6. Greetings Aaron,
    Well, just got time to approach this again.
    The results are in; The tarball is receivable. ๐Ÿ™‚
    The titles look as anticipated — correctly; HomePage, not aneuch.plHomePage. ๐Ÿ™‚
    No more “404 not found”. ๐Ÿ™‚
    One question tho; I notice that while hovering the mouse over the HomePage title link, I now see 2 question marks after
    aneuch.pl. eg; aneuch.pl??do=. Was that intended? While it doesn’t appear to cause any error(s). It may pose issues with any RE’s (Regexes) attempting to modify link(s).
    But otherwise, I’d give it a “2 thumbs up”. Thank you very much for all your time, and attention to th(is/ese) matter(s). ๐Ÿ™‚
    I’ll use this as a reference version, and attempt to merge all of the mod_rewrite nonsense into the config.pl file.
    That is; use Perl, not Apache/Nginx/Lightty/etc… tricks.


    • Great! Glad it works good now!

      As for the double question marks, it won’t cause a problem with Apache (haven’t tested with any other http server though I suspect it wouldn’t give any problems with others either) however I will work on removing it.

      There is a way that you could completely bypass mod_rewrite. Your links would look like http://mydomain/aneuch.pl/HomePage, so they would still be SEO friendly. The CGI variable ‘PATH_INFO’ would include this information. I will look at a way to incorporate this functionality into Aneuch to make it as flexible as possible, however I have to figure out how to make Aneuch aware enough of it’s surroundings to determine which method to use internally. Maybe I can test for the existence of an .htaccess file, and it one doesn’t exist, to use the PATH_INFO method.

  7. OH. See you responded to my earlier post.
    Agreed. In fact, it’d be relatively simple to trap the entire {ENV}, completely clear it, and re-write it to ones’ desired variables. I’m working on it now. I’ll check back, and we can compare notes.


    P.S. Been on BSD since ’77. In fact, I still have the DEC tapes. ๐Ÿ™‚

  8. “Also, I mentioned your name as a thank you on the version 0.21 page: http://aneuch.myunixhost.com/Version_0.21
    OMG! No-o-o-o-o! :O
    Seriously; Thanks. That was kind of you. ๐Ÿ™‚
    On another note; I don’t suppose you have an address I can contact you directly, do you?
    I ask, because I have a couple of files I’d like to share w/you. That I wouldn’t dare post here, I think you might be interested in.


  9. Hello again, Aaron,
    A couple of suggestions;
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">


    <DOCTYPE html>
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

    Also, why not replace: " with <q>.
    Seems like there’s be less to entities to have to scan.


    P.S. Given I don’t have pre tags to work with, I hope the code I posted shows up OK. ๐Ÿ™‚

  10. Greetings Aaron,
    Firstly; I’d like to apologize for being such a dimwit regarding the question about yer email address. It’s boldly posted at nearly the first line of Aneuch.
    I’m afraid a little more sleep, and a few less things on my plate, are in order.
    I have a few things I’m working on with my copy of Aneuch, and I’m wondering if they’re things you might be interested in, and if so; your thoughts.
    I’m building an editor. I took over work on HTMLAREA from Mihai Bazon, several years ago. Advancing it as XHTMLAREA. But, by then, there were so many other forks of it, by CMS authors. That it seemed somewhat a futile endeavor. Anyway, I’ve done quite a bit of work on it, and revisiting it, I got to thinking it’d be pretty easy to use only a subset of it to incorporate it into Aneuch, or simply as a “plugin”. I’m not real excited about using JavaScript in web pages, because it’s somewhat “fragile”; given that turning off JavaScript in your browser defeats it. Also, it can make it (the page that requires it) less available — many text browsers, and such. So I thought it’d fun to explore the possibility of converting much, if not all of it to Perl. Making it a “Dynamic Perl” application. Anyway, just thought I’d mention it. I’ve also managed a “dynamic” menu for Aneuch. Currently it’s Vertical, and Collapsible based on Topics/Categories/Namespaces — some of which, Aneuch doesn’t (yet?) provide.
    A small “nit”; in the CSS block in Aneuch; specifically the @print section; you’ve quoted the font names, none of which have spaces in their name(s):
    body { font:11pt "Neep", "Arial", sans-serif; }
    Just thought I’d mention it. ๐Ÿ™‚


    • I’d be very interested in exploring any changes you might make.

      I’ve considered using an editor such as you mention, which would actually make things a considerable bit easier for people using the engine (they won’t have to memorize syntax rules, etc). However, I’ve always considered something like that as a plugin, rather than including it in the mainline. It could be possible, however anything GPL licensed is immediately ruled out as it wouldn’t be compatible with the BSD license Aneuch currently uses (but it would be fine in a plugin).

      Aneuch does not presently have Topics, Categories or Namespaces. That was something I was considering adding further down the line, once the script itself was fairly “stable” and near full functional.

      Some other features I’m considering adding are database support (likely a plugin, however it might be something I consider adding to the core, as long as it’s a toggle switch for those who prefer not to use it), automatic TOC generation for pages with multiple levels of headings, anti-spam (this is #1 priority right now), and some others. (See http://aneuch.myunixhost.com/Future)

      Not too long ago I was going to begin work on a CMS, however I believe Aneuch is morphing into that eventually, so I refrained from starting another project.

  11. Greetings Aaron, and thanks for the feedback.
    As to licensing; my editor us under a slightly modified MIT/BSD license. So I foresee no conflict(s) there> ๐Ÿ™‚
    Speaking of BSD; when are you going to get off that GNU box you’re on, and use an OS consistent with your license. ๐Ÿ˜‰
    Back to the editor; I should have a functioning prototype done before the days’ out. My dev box; while having a “public” facing IP, blacklists the outside world. I’ll push my working copy on one of my domains, and email you the address, so you can take a peek, if your interested. It will only be _functional_. Reason being; I’ve got some pretty innovative functions, which directly relate to it’s implementation. It will (ultimately — next couple days) be completely self-contained. There will be no need to arrange for icons/images, or support files. Configuration/extensions will/can all be done, either through Aneuch’s config.pl — assuming the editor is part of it. Or through a config of it’s own. Things like different images, and other such things will all be controlled from there.
    As to “Category/Topic/Namespace”; I originally envisioned using the actual directory structure, being used to define such things. It’d be trivial to say; under pages/ create categories/ to use a Category based listing. Or pages/topics/ for a topics based system. Then, of course, pages/namespace(s)/ for a Namespace based one. This, in my mind, would be the quickest/easiest way to initially set up such a system. Then, as time/requests go by; it’d be fairly easy to implement something more complex. Heck; speaking of DB’s; how hard would it to use Perls DB-File, or any of DBIx file based schemes with a CSV file? Anyway, that’s my 0.2ยข. ๐Ÿ™‚
    As to SPAM; Seems (re)Captcha would be a real easy place to start. It could be anything from a simple math problem, to stating what color is being presented to them. While that wouldn’t be fool-proof to those that simply want to “advertize” on a persons wiki. It would be an immediate solution. In fact, I’ve even written a recaptcha. I created it to provide a “service” solution for others. So they could make use of a server that I simply dedicated to providing the service. It’s a simple Perl Module. I could simply install it, create a host name to service it, and off you go. ๐Ÿ™‚
    It uses the typical “scrambled A-Z,a-z,0-9” technique. And works a champ. ๐Ÿ™‚
    As to CMS; yea, I also started down that path. But in the end, a WIKI can, not only easily serve as a BLOG, it makes an easy FORUM. Speaking of FORUM’s; I have nearly finished a Perl based Forum. It turned out pretty nice. But now that everything is nice, and functional. I need to clean it all up, if I’m going to ever offer it’s use to others (as in source).
    Well, I’ve got some more coding to do.
    Best Wishes.


    • RE: Licensing… great! As for the OS, in true UNIX fashion, I use the “best tool for the job.” Maybe it’s not the best, but it’s the easiest. I just don’t have the time to set up BSD on my MacBook, which is temperamental enough under Linux.

      As for the DB’s originally I wanted to write plugins that would utilize SQLite and MySQL. In theory, there’s nothing stopping them from being implemented in the mainline code, but I’d want them to be toggleable (flat files will, in my opinion, always be the default).

      For spam, I’m not a huge fan of captchas as they’ve already a) been shown to have been broken, and b) some are increasingly getting harder to solve by legitimate users (i.e. me). However, my solution is a combination of textcha (similar to captcha but no image) and regex based “content filters”. This would, of course, be customizable by each site administrator. A set of sane defaults would be included, and administrators noticing certain patterns of behavior from spammers can craft rules to block such behavior. These are things I intended to be in Aneuch 0.30. As of now, there is a very simple IP ban in existing installations of Aneuch.

      And finally for the CMS, yea, you’re right, a wiki is incredibly flexible in its applications and usages. There’s very little separation between most common CMS’ and wiki’s.

      I’d like to have a look at your forum some time. Happy coding!

  12. Greetings Aaron,
    About the DB; Understood. I quite agree “file based” is the best way to go. That’s why I spoke of using Directories to handle Topics/Categories/Namespace(s). ๐Ÿ™‚
    I’m also with you regarding Captchas; which is largely why I haven’t created the service. While there is never any sure way to completely prevent SPAM. I rather like Question based, or Simple math the best. User moderation is also a big plus. ๐Ÿ™‚
    I’ll email you a link to the Forum. But please, don’t register, or anything. It’s a development version, and it’s live.
    Thanks for understanding. ๐Ÿ™‚



Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.