[ read the post in context ]
One of my aim for FlatPress was making it *fast*; now, we can all probably agree that a flat file system is not probably the best way to guarantee speed.
In fact, with the word ‘fast’ I don’t mean *absolutely* fast, but *perceived* as fast; this in fact implies answering to a user request as soon as possible, which is generally accomplished by doing the least necessary to show some user interface, and then showing the progress in some way.
e.g. When you download a file, a progress dialog with a bar will show up.
In FlatPress, being ‘fast’ means starting spitting out the part of the page which needs the least effort, and advance progressively.
While this is best practive in common interaction design, it’s not so provably ‘the best’ approach when we speak about web apps and web sites, since spitting out pieces might imply the webserver and the user client will have to negotiate the size of the chunks multiple times, which in turn would make the download bigger… it’s a matter of tradeoffs… which I did consider… and then ignored.
Simply put, if FP loaded all the data into memory before rendering the page, your browser would sit and wait much longer than now.
[see original post on the forum (ita)]
The DateChanger plugin allows for one date selection at the time of the creation; once the post has been created you cannot choose another date for that post.
The question in why.
While it is technically possible changing the date of a post, it is quite complicated, and this is linked to the way FlatPress lays files on the file system (which was inherited from SimplePHPBlog, and which sounded a good idea at the time — I still think it is, since its features make it human intelligible).
Each post is contained in a file POST-ID.txt, which contains, along with the actual text of your post, other pieces of information such as the date; the date is stored in a field called the TIMESTAMP.
Now, POST-ID it is defined in a form which reflects the contained TIMESTAMP field.
Each file is in fact named entryYYMMDD-hhmmss.txt (where YY stands for a two-digit year, MM month, DD day, hh hours, mm minutes, ss seconds), and it is saved under the directory tree
So, say, a post written on January, 1st 2010, saved at 7 o’ clock would be
also, any comment associated to that post would be in a directory called
Each post-id/timestamp is also stored in several indices, one global, and one for each category under which the post has been filed.
Now, suppose you want to change date to that one post, and suppose you have to move it to February, 2nd.
1) You have to update the contained TIMESTAMP field
2) You have to move the file; which means renaming to the new ID and actually move it to another directory tree (in this case fp-content/10/02/); directory tree which might not exist, so you’d add to this creating those directories (also if /10/01 became empty FlatPress would even delete 01! so, sum this one up, too)
3) You have to update each associated index: which translates into deleting the old ID associated to this post, and then add back the new ID.
I believe you can see how many things can fail in the process.
If the ID had no associated meaning (the date/timestamp) you would just have to update the contents and the indices.
Unfortunately, this is not the case.
[see on the forum]
So, since this “doing-multiuser-even-if-I-don’t-want-you-people-to-do-multiuser” is becoming rather popular I’ve decided to put together a very base locking mechanism in SVN.
For those of you interested in the details
it is an exclusive lock on the whole system index, which means one write at a time per entry;
even though the system index is split over several files (one for main, one for each category, and one for the title cache), which would allow for a higher degree of concurrency, you have to remember I am very lazy :P So the lock is global over the whole index.
What does this mean for you
Well, if you’ve been using FlatPress with a single user as it would be meant to be, nothing.
If you have more than one user, then your index won’t probably become corruputed as often as before: when a concurrent access attempts to get a write lock on the index, and the index is being written by someone else, FlatPress will refuse to modify it; but this does not mean you will lose your work! your entry will still be saved as a draft, so you’ll be able to try and save it again, which will eventually succeed, unless another lock has been acquired by someone else in the meantime.
if you are the admin of the system and you are sure that nobody except you is trying to post something, and still you can’t post your entry regularly, then the lock file might have erroneously been kept after the last write: in this case you can delete it manually, you can find it in : fp-content/cache/bpt.lock (bpt stands for B Plus Tree, the underlying data structure).
Have fun with testing!