Fork me on GitHub

Sunday, June 10, 2007

Blog / Roadmap (well, sort of)

Roadmap (well, sort of)

I’ll take this comment as a base for a simple roadmap, or “what’s in the future of FlatPress”.

Friendly URLs

First of all, friendly urls (prettyurls plugin) are *already* in the works! :)

Previous versions (pre-Crescendo) had that as an experimental plugin (which didn’t work really well, though), now I’ve played a little bit more with mod_rewrite and see how it works… and I saw PHP as such facilities that mod_rewrite is just a little “plus”.

I’ve studied more how other scripts work, and so I’m thinking that the best way to accomplish this is breaking a bit the now old URL-compatibility with SPB.

Yes, actually static.php and comments.php are there because I wanted plain URLs compatibility with SPB: I didn’t want my URLs to change because I didn’t want the links in my entries to break, but now I think that I would lose so little that this may be worth the price, what I’m asking is do you think the same?.

I would centralize all of the processing to index.php as is done in other well known and loved platforms such as WordPress itself or wiki systems (MediaWiki or Doku).

Remember that if you always linked ONLY permalinks (in your posts or all around the web) you won’t have any issues: you may have some little problems (but only with links) if you don’t have mod_rewrite (an .htaccess would otherwise send every URL to index.php, as it’s done with WordPress) enabled; in this case you may have receive a 404 error if you tried to browse to comments.php or static.php

I may still add a pair of dummy comments.php and static.php to redirect to index.php for systems which do not have mod_rewrite (cheap hosting and such).

Internal structure

I’ll probably take this occasion to do some rework on how the infrastructure currently works too.

Now we have some master classes which tell the system “which kind” of page (static, comments, etc) you’re viewing; if system will become centralized on index, this may need some rethinking, because it would be probably not as useful as now.

Plugins and widgets

This summer may be time to think about the way plugin will hook the control panel, a feature needed, but still not refined.

Moreover, I’d like to turn widget and plugin panels into something user-friendlier.

Documentation

This is what we really lack, here… -__-’

All of this is not for now: Crescendo is now feature frozen which means that if you won’t find any bug in next two weeks or such, I’ll probably finally release it.

What really stops me is that I should open that damn forum and integrate it into the new website, together with the wiki.

Yes, there is a new website, and even a new domain, a new logo, and new designs (leggero docuit)… stay tuned, guys ;)

  1. Embrance

    Sunday, June 10, 2007 - 17:02:17

    Regarding Friendly URLs. There is another way around without using htaccess file and mod_rewrite. However the page will look like:
    url.com/index.php/you-title-goes-here
    For me t least,that would be the best choice as you minimize the server requirements. And you could have the friendly urls as a plugin on top of that.

    Also a way to turn static pages to HTML one would be the best, to not use the scripts resources everytime a page is called. This could be done with a function(there a ready functions for this)

  2. NoWhereMan

    Sunday, June 10, 2007 - 17:22:04

    > Regarding Friendly URLs. There is another way around without using
    > htaccess file and mod_rewrite.

    that is how WP and such works, and the reason for which I would centralize all to index.php ;)

    > Also a way to turn static pages to HTML one would be the best,

    Hm… yes, maybe.. but I’m not really sure about this one, I still like it the way it is; why not cache the others too, then?

    bye!

  3. Embrance

    Sunday, June 10, 2007 - 17:53:30

    Well yes,caching could work. But you will need to chache certain lements of the page. These would be body content and maybe metatags aong with allo meta info. If you cache other elements,there will be a problem with theme/changes/etc

    Also another thought i had was how fast the script would run on a slash dotting environment? Many visitors,many hits etc? Probably as it is now,it would be a slug and a resource hog. I could help on that, by setting up a testing environment,and trying to make the code as faster as possible.

  4. NoWhereMan

    Sunday, June 10, 2007 - 18:04:06

    Well probably it would be slow; Sure text files do not scale well, but remember that IMO FP should suit a low-traffic and cheap hosting; you’re anyway free to do all the tests you want, that would sure help! we can discuss this further on the ML, if you want :)

  5. Embrance

    Saturday, June 16, 2007 - 03:46:57

    ML suck ass… :P I hate the way SF has them.
    Regarding the speed factor. I saw some DB alternatives, namely txtSQL which is the fastest flatfile DB at the moment. Since from a point on you will break compatibility with older versions, wouldnt it be better to add SQL commands supports using txtSQL?

  6. NoWhereMan

    Saturday, June 16, 2007 - 06:43:22

    Well, no :P

    I’m not breaking so much compatibility… for now I think FP is not that slow, do you?

    I see no use for now in totally breaking even DB compatibility; I don’t know how txtSQL stores its data but I like as the old SPB-style db semantically divided into year and months, even though this means our db is not suitable for general purpose, but for now I wouldn’t mind, really.

    If I had to rethink the storage format, I think I would still do that on my own :)

    Actually *there is* a bottleneck and is in how the entry index works: it will grow bigger and bigger with the number of entries so I should think about spliting it into smaller chunks to be loaded at runtime.

    I’m really a bit worried about that, anyway, on my other site I had a webstat script which tracked visitor accesses: there were ~200 accesses a day, and it took more than two years to fill it up to 8.54 megs (I got a [i]white page of death[/i] (server timeout); every entry was long ~88 Bytes, considering an average 100-200 Bytes (even 500Bytes) for each entry in FP db, and considering you usually don’t post more than one entry a day, the limit it’s (fortunately) quite far to be reached.

    500 Bytes means approx 17,000 entries ( 8,5*10^6 / 500) :)

    bye

  7. weakish

    Monday, July 23, 2007 - 14:21:48

    Almost cannot wait for friendly urls. :)

    Embrance said,
    “that(having index.php within the friendly url) would be the best choice as you minimize the server requirements. ”

    For the same reason, I don’t think using txtSQL is a good idea, since it requires safe_mode turned off.