ℹ️
Welcome to the archive of the old FlatPress support forum. Browse more than a decade of FlatPress wisdom! Login is disabled.

The current FlatPress support forum is available here: forum.flatpress.org
Flatpress powered forums
  • It strikes me as odd and maybe a little disappointing that the Flatpress forum is powered by Vanilla - instead of Flatpress. Flatpress can do so many things. It can *almost* do forums. Flatpress allows comments to be added to entries. But not to other comments. If comments could be commented on, the result would be a simple forum. One way to accomplish this hierarchy would be to save a modified copy of each comment as an entry. Clicking on a comment would display the entry - with all of its comments. What do you think?
  • There is a limitation: the text file. In a forum there could be some user that post in the same moment. Flatpress is very good but it hasn't the possibility by default (oh, yes it's possible but not reccomended) to use multiple user for the same reason. However this is also a limit of SQLite (sorry for my English but I have to answer quickly)
  • The mechanism for accepting multiple comments at once is already within Flatpress. They are simply lined up in a folder under the entry they belong to. So the conflict you are talking about would be making copies of multiple comments as entries? A couple of options here. The first is that the entry could be created when the comment is first saved or later, when a thread is started under the comment. This would reduce the frequency of collisions. As for collisions, I assume the problem is with indexing new entries? Right now, there can be no collisions since a single administrator would only be saving one entry at a time. There could be a conflict between multiple processes attempting to reindex at once. A simple file lock placed on indexing would take care of this. Another option would be to save the files at will, and reindex periodically under a single process. Does this take care of your objections?
  • oonet said: The mechanism for accepting multiple comments at once is already within Flatpress. They are simply lined up in a folder under the entry they belong to.

    So the conflict you are talking about would be making copies of multiple comments as entries?

    Yes, I know how flatpress works. However entries have the B+T indexes to mantain... It's not the same!
    oonet said: As for collisions, I assume the problem is with indexing new entries? Right now, there can be no collisions since a single administrator would only be saving one entry at a time.

    There could be a conflict between multiple processes attempting to reindex at once. A simple file lock placed on indexing would take care of this.

    Another option would be to save the files at will, and reindex periodically under a single process.

    Does this take care of your objections?

    There is already this mechanism, but it's not perfect. However this topic has been already discussed a lot of time. I said the same but about a Flatpress-CMS on July 2010. Non privileged users require an ACL. This is possible (let's see dokuwiki: it's multi user and it's well-done) but to do it is needed to rewrite a lot of plugins or keep some part of old code (such as user_loggedin function) that are still compatible with old releases but it would be a mess. If you want to make a forum based on Flatpress you can do it: it's GPL Software. However I suggest you to use numeric id starting from 1 instead of YYMMDD-HHMMSS because on a forum it's not convenient in my opinion.
  • pierovdfn said: Yes, I know how flatpress works. However entries have the B+T indexes to mantain... It's not the same!

    Yes, the indexes need to be locked from other processes during update. Maybe you are looking for something more refined than a simple file lock? Personally, I wouldn't bother. Locking a reference file to make other processes wait or having a single process update indexes should be fine for all practical purposes.
    pierovdfn said: Non privileged users require an ACL.

    I would consider this an added feature - desirable, but not necessary. Right now, there is no ACL for comments. It wouldn't be needed for hierarchical comments either.
    pierovdfn said: but to do it is needed to rewrite a lot of plugins or keep some part of old code (such as user_loggedin function) that are still compatible with old releases but it would be a mess.

  • Yes, definitely a bother. I'd skip it for now.
    pierovdfn said: If you want to make a forum based on Flatpress you can do it: it's GPL Software.

    Yes, I appreciate that :-) It would take a lot longer for me to complete the project than someone already familiar with the code.
    pierovdfn said: However I suggest you to use numeric id starting from 1 instead of YYMMDD-HHMMSS because on a forum it's not convenient in my opinion.

    I agree with you in principle. To simplify the project, however, I think the current method is fine.
  • If it helps, I just did a test. . . . I copied a comment into the entry directory, replacing "comment" with "entry" in the name. (I did not modify the file.) Next, I reindexed. After that, I went to the address of the new entry (?x=entry:) and saved a series of comments under it. Instant forum :-) Quick and dirty, one small routine could be added to Flatpress to make this a feature: - Add a link to each comment which, when pressed, would copy the comment into the entry directory, reindex, and go to it. (Though best if the comment were copied only once, it wouldn't be terrible if it were copied every time.) Ideally, the link would indicate if the comment contains its own comments or not. Would this be difficult?
  • oonet said: Quick and dirty

    Exactely: dirty...
    oonet said: Add a link to each comment which, when pressed, would copy the comment into the entry directory, reindex, and go to it

    I haven't understood. If you say a "Reply To Comment" link, it would be a great idea, I thought about it some time ago, but most templates should be modified.
  • pierovdfn said: Exactely: dirty...

    You set a high standard!
    pierovdfn said: If you say a "Reply To Comment" link, it would be a great idea, I thought about it some time ago

    Yes, a reply to comment link. I agree it's a great idea. We could be using Flatpress for this forum instead of Vanilla :-)
    pierovdfn said: most templates should be modified.

    No need to modify any templates. The link could go anywhere in the comments area, such as where [delete] now appears.
  • actually an entry could be the first post of a discussion, and comments the comments to that discussion; I don't see the reason for changing that. Apart from multiuser, than you would be just "a theme away" from turning FP into a forum. I have often though about it myself. Concurrent access to the entry index is however a bigger problem, locking and releasing might make the entire platform slower, resulting in a poor user experience. That's why a forum works better with a real DBMS; DBMS are not evil. Trying to recreate the features of a full blown DBMS just because we don't want to use a full blown DBMS makes little sense to me ;)
  • NoWhereMan said: actually an entry could be the first post of a discussion

    Yes.
    NoWhereMan said: and comments the comments to that discussion

    Yes to this too.
    NoWhereMan said: I don't see the reason for changing that.

    Nor do I. The idea is to keep everything pretty much as is.
    NoWhereMan said: Apart from multiuser

    A little care would be needed here to prevent the occasional collision. Either index from a single process (eg cron reindex) or a file lock before indexing.
    NoWhereMan said: you would be just "a theme away" from turning FP into a forum.

    Yes, or it could be done with existing themes.
    NoWhereMan said: Concurrent access to the entry index is however a bigger problem, locking and releasing might make the entire platform slower, resulting in a poor user experience.

    The delay would be when queuing multiple requests to elevate comments to entries. The site would have to be quite busy for this to be happening much.
    NoWhereMan said: I have often though about it myself.

    It seems to fit with the philosophy of your work :-)
    NoWhereMan said: That's why a forum works better with a real DBMS; DBMS are not evil.

    No, not evil. Just less elegant than Flatpress :-)
  • oonet said: No, not evil. Just less elegant than Flatpress :-)

    I'll take that as a compliment, so a big thank you :) However, as a CS graduate, I tend to disagree. DBMSes are far superior than anything FlatPress would ever be able to be, for a number of reasons. If you are developing a very static, low-traffic website, than FlatPress is a nice choice; a wiki is a collection of pages which vary much less often than a forum, so doku is certainly a possibility (even though wikipedia and its 'discussion' pages require a higher level of flexibility); if you plan to handle high-traffic and high-concurrency, then a DBMS is certainly the way to go. It's not only a matter of locking a file to avoid race conditions, if you want reasonable performance then -- for instance -- you want your platform to keep an in-memory cache (in memory, not on disk!); you want to be able to schedule transactions (or at least to be able to plan sequences of operations), and you probably want operations to be atomic and recoverable. I believe you can't accomplish very well any of that from within a single-threaded application which runs only in the context of a single HTTP request.
  • NoWhereMan said: I'll take that as a compliment, so a big thank you :)

    It was intended as a compliment :-) FYI, I reviewed 335 blogs on one PHP site alone, 443 discussion boards, 95 wikis, 271 mailing list managers and 38 social networking applications. With care and for most purposes, I think Flatpress could be adapted to perform these functions better than any of them.
    NoWhereMan said: However, as a CS graduate, I tend to disagree

    You don't need a third party endorsement to disagree with me :-)
    NoWhereMan said: DBMSes are far superior than anything FlatPress would ever be able to be

    Interesting use of terms. By DBMS, I assume you mean a SQL based DBMS? Otherwise, surely Flatpress *is* a DBMS?
    NoWhereMan said: If you are developing a very static, low-traffic website, than FlatPress is a nice choice

    Yes. So at what point does Flatpress start to bog down - and why? What can be done about it? Would you consider Flatpress capable of supporting this forum and your wiki?
    NoWhereMan said: a wiki is a collection of pages which vary much less often than a forum

    How so? In this forum, I see a few comments being added, and none modified or removed.
    NoWhereMan said: doku is certainly a possibility (even though wikipedia and its 'discussion' pages require a higher level of flexibility)

    Right. It all depends on the application. And bigger does not mean better.
    NoWhereMan said: if you plan to handle high-traffic and high-concurrency, then a DBMS is certainly the way to go.

    Okay. And for high-traffic and high-concurrency, an expressway is the way to go. But I'd rather live on footpath :-)
    NoWhereMan said: if you want reasonable performance then -- for instance -- you want your platform to keep an in-memory cache (in memory, not on disk!)

    As a general rule, sure, why not? On the other hand, email is stored on disk, not in memory. And there's exponentially more mail going through most servers than forum comments.
    NoWhereMan said: you want to be able to schedule transactions (or at least to be able to plan sequences of operations), and you probably want operations to be atomic and recoverable.

    Okay. That's a good reason for SQL to exist. Do we need it for our blogs, forums, etc?
    NoWhereMan said: I believe you can't accomplish very well any of that from within a single-threaded application which runs only in the context of a single HTTP request.

    If you only compare the disadvantages of this approach with the advantages of another, your conclusion is inarguable :-) Since you have already written Flatpress, I'm more interested in what it *can* do, than its limitations. You studied power tools for your CS degree. Power tools have their uses. With Flatpress, I think we are talking about craftsmanship.
  • oonet said: You don't need a third party endorsement to disagree with me :-)

    sorry if I sounded arrogant :) it was not intended
    oonet said: Interesting use of terms. By DBMS, I assume you mean a SQL based DBMS?

    not really, I mean any stand-alone Database Management System, running in its own process. It's not only a matter of transactionality, we know that nowadays non-sql non-transactional DBMSes are interesting under particular conditions such as distributed contexts. However FP will never be able to be as performant as any of those.
    Otherwise, surely Flatpress *is* a DBMS?

    well it is, in that it manages a very particular database ;)
    oonet said: Yes. So at what point does Flatpress start to bog down - and why? What can be done about it?

    Would you consider Flatpress capable of supporting this forum and your wiki?

    I really don't know what the hard limits are, I can't give you numbers; however I know that FP would put a high load on the CPU and on disk usage.
    oonet said: On the other hand, email is stored on disk, not in memory. And there's exponentially more mail going through most servers than forum comments.

    That's right. But don't forget that even your mail server runs as a memory-resident daemon. Even regular DBMSes ultimately store files on the disk, it's just that they don't come in a human-readable form; however you can open a binary dump with your favorite text editor and clearly see the contents. The fact that all of these applications use text/binary files for their storage doesn't make them any similar to FlatPress.
    oonet said: How so? In this forum, I see a few comments being added, and none modified or removed.

    I was talking in general. My fear is that if I endorsed the usage of FP as a forum, then people would start to use it wherever it came to their mind. Many cheap, shared hosting providers, where FP is used the most, and where in fact it is mostly meant to live, often ban CPU intensive applications: certainly I don't want FP to be banned from the one place it is meant for!
    oonet said: Okay. That's a good reason for SQL to exist. Do we need it for our blogs, forums, etc?

    I believe that in the case of forums, the answer is yes; as for blogs: it depends. If you like FlatPress and believe you can live with its limited set of features, than it is definitely for you. If you want to do complex queries over your posts or go too much beyond its scope, then I believe it's better looking for something else. For instance, post tagging is something that FP probably will never handle well; neither it will ever handle complex filters such as "show me only those posts filed under these two categories, but not filed under these other three". Those are fields where relational databases shine; on the other hand of course I'm not saying relational databases are the best thing since sliced bread; in fact at the moment I'm more interested in what the cool kids call NoSQL (what old people call document-based DBs), but now I'm digressing ;)
    oonet said: Since you have already written Flatpress, I'm more interested in what it *can* do, than its limitations.

    I see your point. However, as I've said above, I'm still concerned with what the consequences could be
  • @oonet: Flatpress is simple, but Flatpress can more. I have one installation with more than 300 entries in 15 categories. It is my personal scratchpad. It works really fine. On the other hand, using Flatpress as CMS, it only works with a few tricks. Static pages are not in the Flatpress index and can't shown as a search result. So as CMS, you have to use entries without comments. Works on a other installation fine for me. Try Flatpress and find your own restrictions, but be sure, you can do many things with it.
  • NoWhereMan said: sorry if I sounded arrogant :) it was not intended

    Neither was it my intention to say this :-) In my opinion, Flatpress is better qualification than a nod from a government approved institution. More importantly, your comments stand on their own merit. I take them seriously, regardless of what anyone else happens to think.
    NoWhereMan said: I mean any stand-alone Database Management System, running in its own process.

    How does this compare to Flatpress?
    NoWhereMan said: FP will never be able to be as performant as any of those.

    For what purpose? Flatpress publishes web pages with or without a blog. It could also be expanded slightly to include discussions, email subscriptions, online documentation, collaborative design, etc. It probably would not be appropriate for *every* application of this sort. But I think it is well suited for many.
    NoWhereMan said: I know that FP would put a high load on the CPU and on disk usage.

    Perhaps, but only while it is doing something. How busy would a site have to be for there to be many occurrences of two concurrent FP processes? Or three or four? How many FP processes could a small server handle in, say, the 5 or 10 seconds it might take for someone to become impatient? Most discussion groups, for instance, are about as active as this one we are on. At most, they get a handful of submissions per day. Speed is not nearly as important as other factors of design.
    NoWhereMan said: But don't forget that even your mail server runs as a memory-resident daemon.

    The daemon, perhaps, but not the data. The data gets stored to disk.
    NoWhereMan said: Even regular DBMSes ultimately store files on the disk

    Yes.
    NoWhereMan said: The fact that all of these applications use text/binary files for their storage doesn't make them any similar to FlatPress.

    And it doesn't make them any superior either :-)
    NoWhereMan said: I was talking in general. My fear is that if I endorsed the usage of FP as a forum, then people would start to use it wherever it came to their mind.

    Yes, as they do now. So what's the worry? You suggest uses you find appropriate, and hear complaints whenever someone tries something else. You accommodate them if you can. If you can :-)
    NoWhereMan said: Many cheap, shared hosting providers, where FP is used the most, and where in fact it is mostly meant to live, often ban CPU intensive applications: certainly I don't want FP to be banned from the one place it is meant for!

    That's fair :-) So absolutely, this should be a consideration when adding new features. Either the feature needs to be added as a CPU intensive option, or the feature needs to be simple and light.
    NoWhereMan said: I believe that in the case of forums, the answer is yes; as for blogs: it depends.

    Isn't this like saying that a car is faster than a horse? Under what circumstances? What I am suggesting is to have a mechanism for attaching comments to other comments instead of only to entries. I suggested doing this with a link to elevate comments in order to minimize programming. It also adds nothing to current overhead. On the rare occasion when someone chooses to elevate a comment, there would be exactly the same activity as when an administrator adds a new entry. Apart from that, everything would remain the same. Since comments that are commented on could have less ability than entries, a special mechanism could be build to accommodate them. If you think it's worth the effort. Otherwise, I would just use programming that already exists.
    NoWhereMan said: For instance, post tagging is something that FP probably will never handle well

    I agree that for FP installations, tags would probably be more bother than they're worth. We can always define a few extra categories if need be. More useful than tags would be to be able to bulk assign categories (from an index rather than having to change categories one entry at a time). Another possibility would be to have a subset of categories that people could assign to their comments.
    NoWhereMan said: it will ever handle complex filters such as "show me only those posts filed under these two categories, but not filed under these other three".

    Both this and tags are intended for sites where individual readers will never see more than small fraction of the content. I see Flatpress for sites that will actually be *read* :-)
    NoWhereMan said: I'm more interested in what the cool kids call NoSQL (what old people call document-based DBs), but now I'm digressing ;)

    I'm not sure this is a digression. It's your philosophy. Isn't this the architecture of Flatpress?
    NoWhereMan said: I'm still concerned with what the consequences could be

    If we put a button in a car called "windshield wiper," there will be people who wonder why it doesn't wash the whole car. And while washing the whole car would be a nice feature, it is not unreasonable to have a windshield wiper that only washes the most critical part of the car. In this sense, I am suggesting adding a simple mechanism for attaching comments to other comments rather than only being able to add them at the bottom. It's a way to let longer comment threads be more readable. Another way to do this - even simpler than my previous suggestion - would be to add a slightly enhanced quoting feature. If someone wanted to comment on an earlier comment (or comments), they could highlight a section of text and have it copied into their comment panel. The quote would show an ID for the comment being commented on. Readers would be able to follow a conversation by referring to the IDs, perhaps by "live" clicking on them, as they would a footnote reference. One advantage of doing things this way is that most threads tend to be simple and interrelated. Rather than having to follow each thread in isolation, it would all be readable at once. For this to be useful, it would still be helpful for unregistered contributors to be able to start new discussions. Elevating comments to entries is one way to accomplish this.
  • Responding to laborix May 22
    laborix said: I have one installation with more than 300 entries in 15 categories. It is my personal scratchpad. It works really fine.

    Yes, I'll bet it does :-) You could use entries alone for this, or comments as well - to stick simple "post-it" notes on your entries.
    laborix said: On the other hand, using Flatpress as CMS, it only works with a few tricks. Static pages are not in the Flatpress index and can't shown as a search result. So as CMS, you have to use entries without comments.

    If you want search, categories and comments for CMS, you could create the pages as entries instead of statics. Isn't that the difference between entries and statics? Statics aren't indexed because the features that use it aren't needed?
    laborix said: Try Flatpress and find your own restrictions, but be sure, you can do many things with it.

    True! And then, where there is a restriction, we look for a simple way around it :-)
  • Static pages can be used for widgets in your blog. This is one reason, why they aren't in the index. Aside from that, Flatpress is designed as a easy to use blog, not as CMS or forum.
  • laborix said: Flatpress is designed as a easy to use blog, not as CMS or forum.

    What is missing from Flatpress that you'd need for a CMS? As for forums, the main thing missing seems to be the ability for readers to start a new discussion. The software can handle discussions just fine right now, using comments, a change in subject can't be separated into another thread. Is there anything else you think is needed for Flatpress to handle discussions such as the one we are now having? So far, our discussion has received posts from 4 people, with a couple of threads interleaved. What is Vanilla doing for us that we couldn't do as well with Flatpress? And assuming there are a few things, what would be the harm in adding them?
  • oonet said: What I am suggesting is to have a mechanism for attaching comments to other comments instead of only to entries.

    the more I read this, the more I think that what you call a forum is what I wold call comment threading
    oonet said: I'm not sure this is a digression. It's your philosophy. Isn't this the architecture of Flatpress?

    heh. I guess FP might have something to do with this interest of mine ;)
    oonet said: Another way to do this - even simpler than my previous suggestion - would be to add a slightly enhanced quoting feature. If someone wanted to comment on an earlier comment (or comments), they could highlight a section of text and have it copied into their comment panel. The quote would show an ID for the comment being commented on. Readers would be able to follow a conversation by referring to the IDs, perhaps by "live" clicking on them, as they would a footnote reference.

    ...and this description of yours tends to confirm. Have you ever heard about disqus? :) I have never bothered to see how it can be added to FlatPress but I think it's enough to put a bunch of tags around and disable FP's native comment system. Disqus is a fine idea, since you put the strain all on the third party, rendering FlatPress much more static. Of course, on the other hand you lose the internal FP commenting capabilities, but they are in fact much more limited than what Disqus offers. Comments cannot be 'promoted' to full-blown entries, but it's a little more forum-like.
  • Just a comment on FP performance... I have one installation with ~700 entries and some 20ish static pages, and doesn't see any performance problems with FP. I once tried using WP for the same site a few years ago, and that hogged resources really bad. The site became really slow and the level of irregular error 500 pages literally shot through the roof. So imho FP performs better :)
  • Just a comment on FP performance... I have one installation with ~700 entries and some 20ish static pages, and doesn't see any performance problems with FP. I once tried using WP for the same site a few years ago, and that hogged resources really bad. The site became really slow and the level of irregular error 500 pages literally shot through the roof. So imho FP performs better :)
  • Yes, but as NoWhereMan said and as I said in my first reply, for a forum a DBMS is needed. You can't use text files because of lock mechanism etc, especially with a big community. However a lot of users says that wordpress isn't a very good software for many reasons.
  • Responding to NoWhereMan May 24:
    NoWhereMan said: the more I read this, the more I think that what you call a forum is what I wold call comment threading

    I am talking about comment threading. Threaded posts. Discussions. How would this be different from a forum?
    NoWhereMan said: I guess FP might have something to do with this interest of mine ;)

    Yes . . . and it's part of what makes Flatpress interesting :-)
    NoWhereMan said: Have you ever heard about disqus?

    Yes. Blech!
    NoWhereMan said: Disqus is a fine idea, since you put the strain all on the third party, rendering FlatPress much more static.

    Yes. For the sort of installations that would benefit from SQL. Cars are bigger, better, faster than bikes. But a great roof rack for a car, is not necessarily the best way to carry groceries on a bike. Nor is an avid bicyclist necessarily interested in "upgrading" to a car.
    NoWhereMan said: Comments cannot be 'promoted' to full-blown entries, but it's a little more forum-like.

    Yes. At the time, I was talking about an enhancement that could *almost* replace the basic ability of being able to promote comments to entries. The ability is already within FP so it wouldn't be loaded down by adding it. What I am looking for is a link to trigger it. With the ability to promote comments to entries, I think FP would handle discussions better than Vanilla. I suggested the elevating method to save programming. As you said, though, what I'm really talking about is threaded comments. Ideally, you would click on a comment you want to reply to and it would be copied into a text box. Quoted text might be preceded with a > (as in email), or enclosed in [quote][/quote] or tagged invisibly. This way, we wouldn't need to constantly run back to the original comment for the next piece. To read a discussion, a single thread would display, without interruption. Some of the comments could be clicked to follow a side track (and return). Or maybe the comments could display in two columns. Main thread and side threads. Less clicking and hiding. Does this make sense?
  • Responding to macmathan May 24:
    macmathan said: I have one installation with ~700 entries and some 20ish static pages, and doesn't see any performance problems with FP.

    Excellent! Do you see any *difference* in performance compared to an installation with only a couple of entries?
    macmathan said: I once tried using WP for the same site a few years ago, and that hogged resources really bad. The site became really slow

    With ~700 entries? Was it as slow with only a couple of entries? Was it a dedicated system - or was it perhaps overloaded? To be fair, I've run WP with thousands of entries and no perceptible delays. This doesn't mean that I don't agree that FP outperforms WP in terms of speed. I think the comparison could go either way, depending on the circumstances.
    macmathan said: So imho FP performs better

    In which case, maybe there's room to do more with it :-)
  • Responding to pierovdfn May 24:
    pierovdfn said: Yes, but as NoWhereMan said and as I said in my first reply, for a forum a DBMS is needed. You can't use text files because of lock mechanism etc, especially with a big community.

    Maybe your communities are bigger than mine :-) What about using Flatpress for small forums then?
    pierovdfn said: However a lot of users says that wordpress isn't a very good software for many reasons.

    Wordpress is one option, but there are others. Such as, for discussions, Vanilla. Vanilla is handling this one discussion about as well as Flatpress without modification. If Flatpress could just be made to handle more than one discussion, I see no reason to use Vanilla instead. With a couple of minor enhancements (for threaded discussions), I think it would be *better* than Vanilla. Could Vanilla handle *larger* discussions than Flatpress? Very likely. But who cares if 99% of discussion boards receive fewer than 100 postings per day? Could Flatpress handle 100 postings per day?
  • oonet said: Wordpress is one option, but there are others.

    It was to reply to macmathan, that provided Wordpress as an example. I think Vanilla isn't so bad... Vanilla has also the user-part made with AJAX, Replies Drafts (in FP would be comment drafts) that Flatpress hasn't now. Have you thought that in a forum discussion are ordered by last post? So you should index also comments... Last comments works but not so well... It has a temporary file with last comments but when you delete cache you delete also this file. However... The entry would be the first post, so user should make it. It's not so difficult, you add an ACL to FP, I've already done a lot of time ago (I've integrated FP with Ultimate PHP Board, a flat-file board). Then users could create new entries but wouldn't be able to delete/edit discussion of other users (obviously you create a lock-mechanism). Users replies to that discussion with comments. Maybe you create a good theme that a blog seems a forum. You modify the last comments plugin and you make it working to order posts with my fake-category method (http://www.vdfn.altervista.org/2010/08/09/flatpress-far-vedere-post-non-apparentemente-collegati/). It's a bit hackish but you would have the forum. However there are a lot of other things to care: the search or the speed of lastcomments method: you'll have a big file: how do you handle it? It's more complex that having categories sorted opposite to others (from older to newer and from newer to older).
  • pierovdfn said: It was to reply to macmathan, that provided Wordpress as an example.

    It doesn't seem to be. . . . I can see FP handling our conversation better than this :-)
    pierovdfn said: I think Vanilla isn't so bad...

    No, not bad. But somewhat bloated and cumbersome. We are using it for this discussion of Flatpress. I think Flatpress could do the job better.
    pierovdfn said: Vanilla has also the user-part made with AJAX, Replies Drafts (in FP would be comment drafts) that Flatpress hasn't now.

    Drafts might be a nice enhancement, though not essential. Especially if it's convenient to compose comments in an external editor.
    pierovdfn said: Have you thought that in a forum discussion are ordered by last post?

    Are you saying that you prefer forum posts to be displayed in reverse order of submission?
    pierovdfn said: So you should index also comments...

    Yes. Indexed, chained or appended to a single file (like sendmail).
    pierovdfn said: Last comments works but not so well...

    The Last Comments plugin you mean? Yes, it displays comments even after they have been deleted.
    pierovdfn said: However... The entry would be the first post, so user should make it.

    Yes. Currently, only the administrator can add entries.
    pierovdfn said: It's not so difficult, you add an ACL to FP

    That's an option, but for most boards, it would be better without.
    pierovdfn said: I've already done a lot of time ago (I've integrated FP with Ultimate PHP Board, a flat-file board).

    I'm not wild about Ultimate PHP Board, but what you did to integrate it is far more elaborate than what I'm talking about :-)
    pierovdfn said: Then users could create new entries but wouldn't be able to delete/edit discussion of other users (obviously you create a lock-mechanism).

    Yes, this is one way to do it. Expand the ACL in Flatpress to allow contributors to start conversations. Or it could be done without ACL. Whatever is easiest.
    pierovdfn said: You modify the last comments plugin and you make it working to order posts with my fake-category method

    Why last comments? It would interleave all discussions into a flat list instead of threading them.
    pierovdfn said: However there are a lot of other things to care: the search or the speed of lastcomments method: you'll have a big file: how do you handle it?

    Maybe it would be better without lastcomments?
  • @oonet: what piero is trying to say is that usually conversations are ordered by the date of the last comment in the thread, FlatPress can only order by the date of the first post. btw, comment threading is usually accomplished by putting the id of the comment you are replying to into the tuple of your own comment (I'm talking about the backend) say: id : 1 text : some comment parent : null id : 2 text : hey I'm replying parent : 1 the problem here is that, since you cannot do JOINs, you have to find a way to iterate over comments to display them correctly, which is not what FlatPress was designed for: it wouldn't work with the way themes work currently. However, I've seen several time some JavaScript wizardry on WordPress which rearranges themes to be nested/threaded. So this is (theoretically) feasible.
  • NoWhereMan said: what piero is trying to say is that usually conversations are ordered by the date of the last comment in the thread, FlatPress can only order by the date of the first post.

    Okay, then I did understand correctly. This discussion in Vanilla is first to last. Would it be a problem if Flatpress did it the same way?
    NoWhereMan said: you have to find a way to iterate over comments to display them correctly, which is not what FlatPress was designed for

    You don't mean jumping to NoWhereMan said: However, I've seen several time some JavaScript wizardry on WordPress which rearranges themes to be nested/threaded. So this is (theoretically) feasible.

    Yes. So what would be best from the user's point of view?
  • oonet said: Okay, then I did understand correctly. This discussion in Vanilla is first to last. Would it be a problem if Flatpress did it the same way?

    yes, unless you want to rely on a modified lastcomments plugin pretty much as Piero suggested; however the lastcomments plugin is way to simple and it wouldn't be enough, you would have to modify the indexing backed heavily to support such a feature.
    oonet said: You don't mean jumping to a name="?

    No, I'm talking about threaded/nested comments; having replies attached to their parent. Otherwise it is very easy to "jump" to a name each comment in a properly designed theme has an id; you just have to link to #id-of-the-comment for instance, if you are replying to comment123456-123456, you just have to create a link @some-guy-you-are-replying-to you can already do that, it's just nobody have ever bothered ;)
    oonet said: So what would be best from the user's point of view?

    it's mostly a matter of taste. If there a lot of people involved in a discussion, then usually threading is better; on the other hand if usually a discussion does not involve many people (as it happens on this forum, for instance) the linear + jump approach is generally ok (in my opinion)
  • For ACL: I call ACL also the basic is_admin command because you're checking if an user can do some action, so there is already a very small ACL. However in a good forum you have to allow users to register. It's a basic thing, in my opinion.
    oonet said: Why last comments? It would interleave all discussions into a flat list instead of threading them.

    It's an alternative to index every comment. I provided just as a basic example.
    oonet said: Yes. Indexed, chained or appended to a single file (like sendmail).

    I haven't understood.
    NoWhereMan said: yes, unless you want to rely on a modified lastcomments plugin pretty much as Piero suggested; however the lastcomments plugin is way to simple and it wouldn't be enough, you would have to modify the indexing backed heavily to support such a feature.

    And here we return to trees discussions :) In this case a DBMS would be better because it's very faster to sort.
    NoWhereMan said: the problem here is that, since you cannot do JOINs, you have to find a way to iterate over comments to display them correctly, which is not what FlatPress was designed for: it wouldn't work with the way themes work currently.

    I've thought a lot of times that you if you want to keep current themes you should register an "hacked" comments block to smarty. With this method the real problem of themes are numbers (if you use ol tags) and padding. For hierarchy XML would be human-readable and semantically correct but a script take time to parse it. However the fix-length of comment id that flatpress has can help: you could use pack function with strings and then parse a linear file but you could take time do also this thing. I would remain to backend before talking about the user experience.
  • NoWhereMan said: yes, unless you want to rely on a modified lastcomments plugin pretty much as Piero suggested

    Vanilla is first to last without enhancements. Flatpress comments are also first to last. It seems the same to me. Why mess with lastcomments?
    NoWhereMan said: No, I'm talking about threaded/nested comments; having replies attached to their parent. Otherwise it is very easy to "jump" to a name

    Since it is easy to jump to a name, why not start with that?
    NoWhereMan said: each comment in a properly designed theme has an id; you just have to link to
    #id-of-the-comment

    Yes. I see it in comments.tpl. How about a link in each comment that, when clicked, would copy a reference link to the new comment (in the body or attached to it)? The link would show the parent id and clicking it would jump back to it. (Also, the comment could be copied into the comment for chopping up into quotes.)
    NoWhereMan said: it's mostly a matter of taste. If there a lot of people involved in a discussion, then usually threading is better; on the other hand if usually a discussion does not involve many people (as it happens on this forum, for instance) the linear + jump approach is generally ok (in my opinion)

    Yes. We have been talking about at least both of these two methods at once :-) The first thing I am thinking of it a simple way to accomplish discussions as well as Vanilla, or, for most purposes, slightly better. We don't need every enhancement we have been discussing. Just enough to get started.
  • Sorry about the triple posting! Flatpress.org is running *very* slowly today. As far as I can see, there is no way for me to delete the duplicates?
  • pierovdfn said: For ACL: I call ACL also the basic is_admin command because you're checking if an user can do some action, so there is already a very small ACL.

    Yes. And it might be nice if we could at least create multiple admins more easily.
    pierovdfn said: However in a good forum you have to allow users to register. It's a basic thing, in my opinion.

    Why do you think it is important? For many purposes, I would prefer to do without. I wouldn't mind having it as an option.
    pierovdfn said: It's an alternative to index every comment. I provided just as a basic example.

    Why do more than the current commenting structure allows?
    pierovdfn said:
    oonet said: Yes. Indexed, chained or appended to a single file (like sendmail).


    I haven't understood.

    There needs to be some way for multiple comments to appear in a list. They can be stored in separate files, indexed by an index file; stored in separate files, chained to next by an index within the same file; or all the comments can be appended in order to a single file. Since there are no insertions, a single file would be fine.
  • As an experiment, I tried using the tag plugin to manage threads. The feature works in entries but not in comments. Is there a convenient way to enable tags in comments? Tags could be the mechanism for allowing unregistered posters to promote their comments into readable channels. A user would reply in order, but tag their comment if they think it's something of a digression. To be readable, conversations would be followed by tags rather than the main entry with all its comments.
  • oonet said:
    Vanilla is first to last without enhancements. Flatpress comments are also first to last. It seems the same to me. Why mess with lastcomments?

    You're wrong. Entries in Flatpress are ordered by creation date. Just for example: Entry A: Creation Date 10 Oct 2010; Last Comment: 25 Mag 2011 Entry B: Creation Date 10 Mag 2011; Last Comment 11 Mag 2011 Flatpress: Entry B is the first in the list; Vanilla (and every forum) Entry A is the first in the list.
    oonet said: Since it is easy to jump to a name, why not start with that?

    It's easy for users but not for the script. You have to thing differently than now (if you want to use the "padding" system).
    oonet said: Why do you think it is important?

    To grant that is always the same user to reply or to let him edit his comments.
    oonet said: There needs to be some way for multiple comments to appear in a list. They can be stored in separate files, indexed by an index file; stored in separate files, chained to next by an index within the same file; or all the comments can be appended in order to a single file. Since there are no insertions, a single file would be fine.

    Ok, I thought it was something more precise. However this is the sticking point: Flatpress comment system is quite nice because it's a great function but it's like a guestbook in my opinion. They're listed every time, I don't see a cache or an index that is the difference between comments and entries (talking about backend, not frontend...).
    oonet said:
    How about a link in each comment that, when clicked, would copy a reference link to the new comment (in the body or attached to it)? The link would show the parent id and clicking it would jump back to it. (Also, the comment could be copied into the comment for chopping up into quotes.)

    You can already do, you don't have to modify core files, just make a plugin.
    oonet said: As an experiment, I tried using the tag plugin to manage threads. The feature works in entries but not in comments. Is there a convenient way to enable tags in comments?

    My tag plugin? (http://www.vdfn.altervista.org/redirect/plugin_tag.html) Maybe I'll explain later what are the limits of this plugin. I'm sorry for my English but it isn't my mother language but I'm interested on this purpose.
  • pierovdfn said: Flatpress: Entry B is the first in the list; Vanilla (and every forum) Entry A is the first in the list.

    Ah, now I see what you're saying. You were looking at Flatpress entries. I was looking at Flatpress comments. The fact that entries are reverse ordered shouldn't matter because while we would be using the entry feature to manage comment hierarchy, we only need one entry at a time. Clicking a comment brings it up as an entry followed by all its comments. Grouping entries reverse order is not needed for forums, but it could be useful. A reader looking for a specific subject could scan threads conveniently by reverse order of date. Then the thread would be read from first to last. Exactly as Flatpress is designed to work as a blog.
    pierovdfn said: It's easy for users but not for the script. You have to thing differently than now (if you want to use the "padding" system).

    Right. So if "padding" is difficult but a local link would be easy, skip about with local links. (Or choose one of the other methods we have talked about.)
    pierovdfn said: To grant that is always the same user

    Right now, I seem to recall Flatpress tracks users with cookies. That should work. Otherwise, the user would choose what name to give for each comment.
    pierovdfn said: let him edit his comments

    Edit and delete? Yes, this is nice. If it's easy enough to implement. Otherwise, we do without. I've noticed that some people edit while others never do. Most people who edit, don't edit regularly and when they do, there is often a mess with feeds. In my opinion, provide the feature if it's convenient. If not convenient, save the effort for something more important.
    pierovdfn said: However this is the sticking point: Flatpress comment system is quite nice because it's a great function but it's like a guestbook in my opinion. They're listed every time, I don't see a cache or an index that is the difference between comments and entries (talking about backend, not frontend...).

    Okay. But isn't this guestbook facility also good for conversations? Comments could all respond only to the main entry at the top - not to each other. To respond to another comment could always mean promoting it to an entry. Another approach would be to respond, as we are doing now, to recent comments, quoting from them and/or referring to them by ID. In this case, only off-topic would be elevated to an entry. And a third approach would be to thread comments - with tags or some other index - without moving them from their sequence in the guestbook. Instead of elevating comments and using the existing programming for entries to manage them, a new facility would apply to threaded comments - perhaps borrowing from the entry program, perhaps not.
    pierovdfn said: You can already do, you don't have to modify core files, just make a plugin.

    Yes, ideally this is what I meant. Ideally, plugins could handle everything I am talking about. To write plugins, is there any documentation - or just trial and error?
    pierovdfn said: My tag plugin? (http://www.vdfn.altervista.org/redirect/plugin_tag.html)

    Yes, that's the one I tried. It worked perfectly in entries. But in comments, only bold, italic etc tags appear to be interpreted. The url tag, your tag tag, and other more advanced tags just show up in the text.
    pierovdfn said: I'm sorry for my English but it isn't my mother language

    You have no reason to apologize! If you hadn't said, I would never have known.
    pierovdfn said: I'm interested on this purpose.

    Good . . . how fun :-)
  • oonet said:
    pierovdfn said: To grant that is always the same user


    Right now, I seem to recall Flatpress tracks users with cookies. That should work. Otherwise, the user would choose what name to give for each comment.

    Cookies are not secure because of two reasons: 1) users can edit (identity theft) 2) with username and password you can login with the same account in every computer you want. However this is not the first point of a forum. For comments "padding": it's for comments. For a forum quotes are better, so there aren't problems.
    oonet said: Yes, that's the one I tried. It worked perfectly in entries. But in comments, only bold, italic etc tags appear to be interpreted. The url tag, your tag tag, and other more advanced tags just show up in the text. [...] Yes, ideally this is what I meant. Ideally, plugins could handle everything I am talking about.

    To write plugins, is there any documentation - or just trial and error?

    Yes, I know. Tag is a bit hackish because I wanted to have "free" categories. It works quite well but it's not native. This is why a Flatpress Forum would be a fork of flatpress. To improve it you should modify core files. However you could extend tag to comments, it should be so difficult but is boring for users tagging the post. To write a plugin there isn't documentation. You have to understand the Flatpress code. Nay there is documentation in the net but not so much. For the order question: I think you must sort entries by last comments date rather than edit date, so active threads would be above recent but inactive topics. Yesterday I said that I was interested on the topic but I have not time to mantain this project but I could help occasionally. I have no a community that would use a forum. I had one but nobody used. Now users love social networks.
  • pierovdfn said: Cookies are not secure because of two reasons:
    1) users can edit (identity theft)
    2) with username and password you can login with the same account in every computer you want.

    Cookies aren't secure if using them for security, no. But I was just thinking of them as a way to save people typing in their info more than once - instead of for every post. Either way is fine. Typing a nickname doesn't take that long.
    pierovdfn said: However this is not the first point of a forum.

    No. So unless it is very easy, I would start without, and add conveniences after everything else is working.
    pierovdfn said: For comments "padding": it's for comments. For a forum quotes are better, so there aren't problems.

    I guess it's whatever seems simplest and most elegant with whatever else is chosen. Another possibility would be to use the Expand plugin from lantaca to expand and collapse comments as an outline.
    pierovdfn said: Tag is a bit hackish because I wanted to have "free" categories. It works quite well but it's not native.

    Yes, it looks good. Applied to comments, it alone could let us do forums :-)
    pierovdfn said: To improve it you should modify core files.

    Personally, I see no reason for a blog with comments but no discussion. Therefore, I see forums as a core function. The main thing is to have the ability, by whatever means.
    pierovdfn said: However you could extend tag to comments

    Good! How?
    pierovdfn said: is boring for users tagging the post.

    Yes, I agree. That part isn't ideal. I'd think about a simple procedure to make it easier for them. Or maybe we could think of a helpful way to hide them in a template.
    pierovdfn said: To write a plugin there isn't documentation. You have to understand the Flatpress code. Nay there is documentation in the net but not so much.

    That's what I was afraid of! Just modifying styles and templates has already proven time-consuming and messy. Printing pages, for instance, steadfastly ignores my efforts to narrow the margins (widen the body). I'd rather see this done right :-)
    pierovdfn said: I think you must sort entries by last comments date rather than edit date, so active threads would be above recent but inactive topics.

    Yes, sorting or separating to make active conversation easier to find.
    pierovdfn said: I have no a community that would use a forum. I had one but nobody used.

    It's true. People don't *use* forums. It's very hard to market a forum or blog unless you are a big company. And even then. However, people do talk about what interests them. Set up a forum and start talking about what interests you. Invite people to talk about what interests them. If nothing else, you should have fun :-)
    pierovdfn said: Now users love social networks.

    You mean the big name networks? Yes, more people go to big things than small things. That's what makes them big. Doesn't make small things any less valuable, though. If anything, it makes it more worth our efforts to preserve them. I don't expect Flatpress to ever replace the big social networks. However, I absolutely think it could be better for people.
  • oonet said: Personally, I see no reason for a blog with comments but no discussion. Therefore, I see forums as a core function. The main thing is to have the ability, by whatever means.

    Ok, but with "core files" I meant the Flatpress files, I think it's difficult get all the functions with plugins. For tag plugin, you can keep the database but you have to modify some things but I don't know if you can get entry id from a comment id... It would be useful.
  • pierovdfn said: Ok, but with "core files" I meant the Flatpress files, I think it's difficult get all the functions with plugins.

    Fair enough. It might be best through core files rather than plugins. Unless working with core files is a problem. In which case, we use whatever means are open to us.
    pierovdfn said: For tag plugin, you can keep the database but you have to modify some things but I don't know if you can get entry id from a comment id... It would be useful.

    Yes. It might be that we can only get a sequence of tagged comments without an entry. While it might be nice to get the entry, it's not essential. There are several ways I can see the feature being used. Without making any changes to Flatpress other than to enable tags for comments, it would be possible to implement forums. Categories would define a number of topics. A single entry under the topic would document the topic without being part of a discussion. Someone would start a discussion under the topic by posting a comment, and assigning it a tag. The next person would then start another new discussion as a second comment, or click the first comment to bring up all the comments with that tag. This would be the thread that they would then comment on. The new comment would be tagged to show up with the others. All but the first comment in a thread would be stored in a comments folder without a parent entry. The advantage of this approach is unregistered contributors could start discussions and respond to them without needing to promote comments to entries. I am assuming that the mechanism used to tag comments would be capable of this?
  • How about this? A start discussion form that allows unregistered (or low level registrants) to create entries for subsequent commenting. Categories could be used to organize discussions by topic. Only a subset of categories would be available for the purpose, specially identified (by name, prefix, numeric id, symbol, hierarchy or whatever) in the categories list. New (start of discussion) entries could be indexed individually, or by reindexing all entries after submission or periodically by cron. Conversations could be a single list of comments under an entry, or "branching" could be permitted. Given this basic ability for contributors to start new discussions, we could let users track long conversations manually, or add a simple quoting scheme. What do you think?
  • Yes, it could be. Maybe you could use radios instead of checkbox for categories (in a forum you can't post-crossing). Entries are already indexed, so you won't need cron to index them periodically. I don't think branching it's a good idea at the beginning, maybe you could add later.
  • pierovdfn said: Maybe you could use radios instead of checkbox for categories (in a forum you can't post-crossing).

    Makes sense. Radios, pulldown or automatic.
    pierovdfn said: Entries are already indexed, so you won't need cron to index them periodically.

    This is true for entries created by the administrator.
    pierovdfn said: I don't think branching it's a good idea at the beginning, maybe you could add later.

    By branching, you mean starting new discussions? Assuming this is what you mean, maybe what matters most is a simple quote feature. To facilitate more of a discussion between people commenting on blog posts. Makes sense.
  • oonet said: This is true for entries created by the administrator.

    All users that can use the admin entry panel should be able to post. Now just admin entries are indexed because just admins can create entries.
    oonet said: By branching, you mean starting new discussions?

    I mean Reply to a comment.
  • pierovdfn said: All users that can use the admin entry panel should be able to post. Now just admin entries are indexed because just admins can create entries.

    Right. Which means that only admins can start discussions . . . so we use Vanilla for our discussions instead of Flatpress.
    pierovdfn said: I mean Reply to a comment.

    You aren't in favor of branching. What about some sort of quoting function? People read the main article and some or all of the comments, then write their own comment. They might want to refer to something said in the main article or in one or more of the comments. How do you suggest they do this?
  • oonet said: Which means that only admins can start discussions . . . so we use Vanilla for our discussions instead of Flatpress.

    Exactely. You should add an ACL, as I always said.
  • pierovdfn said: Exactely. You should add an ACL, as I always said.

    Yes, adding an ACL would be good if anyone cares to do it. Unfortunately, this doesn't seem to be high on anyone's list of things to do :-) So does that mean we can't make it easier for people to refer to other comments when they comment? And does that mean we use Vanilla instead of Flatpress for our forums? Whether someone writes an ACL or not - which would be nice - I see the need for forums that allow unregistered contributors to start new discussions. Do you have an objection to unregistered contributors, or is it that you simply don't see the need?
  • I would write an ACL System for Flatpress. I've already written a bridge for FP<==>UPB but you need to change a lot of core files and so you have to update this bridge with every release of Flatpress and it's a boring work. Moreover Flatpress already has its standards: you should have two APIs for users: one is the old API, just for administrators and the second is for all users (non privileged and admins). However the best way to add a small ACL to Flatpress (just privileged - non-privileged, at least at the beginning) is adding some hooks, so if you want to have an ACL you improve it with plugins.
  • pierovdfn said: I've already written a bridge for FP<==>UPB

    Ultimate PHP Board? Yeah, that's way more work than I was thinking. Also, it sort of replaces FP with something else. I was thinking that FP could be that something else :-)
    pierovdfn said: you have to update this bridge with every release of Flatpress and it's a boring work

    Yes, that sounds like a real hassle!
    pierovdfn said: However the best way to add a small ACL to Flatpress (just privileged - non-privileged, at least at the beginning) is adding some hooks, so if you want to have an ACL you improve it with plugins.

    Sounds good. I'm noticing that Vanilla has an ACL. If FP had one, it would be nice. On the other hand, I'm looking at what the ACL is doing for this particular forum. What would happen if there was no ACL? If we could all read and contribute freely, without logging in? FP has been designed to host blogs. It accepts comments without an ACL. What do you see happening with forums that ACL isn't required for a blog but would be for a forum?
  • oonet said:
    Ultimate PHP Board? Yeah, that's way more work than I was thinking. Also, it sort of replaces FP with something else. I was thinking that FP could be that something else :-)

    Yes, obviously if you have to transform FP in a forum you'll make an authentication for it, but it was to saying that I know what does this work mean. Just administrator could edit the posts. The user that has a profile it's part of an existent community; if there aren't users there is no community. Yes, you could say that there are users, the users that posts but it wouldn't be the same: they are visitors of a group, not members.
  • 12
    This discussion has been closed.
    All Discussions
    Start a New Discussion

    Howdy, Stranger!

    It looks like you're new here. If you want to get involved, click one of these buttons!

    Categories

    In this Discussion