ℹ️
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
Improving the Static Pages List
  • Since I’m storing books as Flatpress static pages for about half a year or more, I’ve started thinking about improving their list.
    Before Hyperpage was invented, I had to cut books like Nicky to several files since 2 megabytes for a single page is too much. But this results in long listings on the Static Pages List. In this hour I’m Hyperpage-ifying Nicky to shorten the listings, but…
    Apparently, static pages are stepchildren in Flatpress. You can create static pages, edit, delete and display them, and that’s all. They were designed to provide pages for a blog like About Me, About My Company, About My Kitten and so on, simple pagelets to be listed in a widget. I believe NoWhereMan didn’t think about more than, say, five static pages to be needed for a blog. Some minutes ago I had 116 static pages, and after unifying books into Hyperpage documents, about 65 are expected to remain. They include single-static-page and multi-static-page novels, short stories, story fragments, studies on several topics, a Contents page listing my books, programs like my theme changer or my Chinese character micro-dictionary (and its database as another static page), unpublished work-in-progress books, some private documents, temporary documents for experimenting with new BBCode tags…
    All of them in the same folder and the same listing.

    That’s ridiculous for such a professional system as Flatpress. Obviously we can do much more. We, not me; most of it should be handled in tpl files, the part of Flatpress I know the least about. I don’t know how to do, just what to do.
    I’m thinking about static page folders. Let me create folders inside fp-content/content/static (the root) and put pages and additional folders in them. Call the listing page as admin.php?p=static to display pages and folders in the root, and when a folder name is clicked, call it as admin.php?p=static&folder=foldername to display pages and folders in that folder. When a page in the root has to be edited or displayed, nothing changes; pages in folders are now edited as admin.php?p=static&action=write&page=folder:subfolder:subsubfolder:page and displayed as /?page=folder:subfolder:subsubfolder:page. Very easy.
    What do you think?
  • Having no reaction for the above, I started to think how to develop it. First, I went to core.static.php and changed the first statement as follows:
    define('STATIC_DIR', CONTENT_DIR . 'static/'.$_GET['dir'].'/');
    Now the listing works correctly for subdirs in static, if I add a URL parameter dir=subdirname. I added also
    function static_getlist() {

    $obj = new static_indexer;

    $list = $obj->getList();

    // LAttilaD
    natsort($list);
    $list=array_values($list);

    // for static dirs
    for($a=0; $a<count($list); $a++)
    if(is_dir(STATIC_DIR.$list[$a]))
        {
    $fd=$list[$a];
    unset($list[$a]);
            $list=array_merge(array($fd), $list);
            $a--;
        }
    // LAttilaD end
    return $list;

    }

    Now folders are listed on top of files, similar to Total Commander. But they aren’t sorted yet.
    The next step should be to turn folder names into links to add or change the dir URL parameter and list contents of the folder. That’s the point I’m stuck at now.

    NoWhereMan, please tell me if I’m preaching to the choir and you’re working on it already. :)
  • I wish I had time to work on that, but no, I'm not.

    I like the ':' separator idea, but remember that then ?x=page:some:dir:page:name would not work. You might want to use ?x=page:some/dir/page; in this case prettyURLs might require some trickery (line 399: slashes should then be allowed).

    I'd rather NOT put $_GET['dir'] in that that define, or else you are gonna have a bad time.

    exercise for the reader: suppose a malicious user writes ?dir=../../some/interesting/file/of/yours

    I'd rather allow colons or slashes in static page names and *then* check for the validity of that path+file name. That would go right into static_save() and static_exists() (IIRC) I don't think TPLs would probably change much.

    Really, there is a reason for which static pages are left quite aside. You can now hide any category from the front page using the FrontPage plugin and then create a custom static-page-like link using a plugin such as @pierovdfn's "redirect". Of course the file system layout would be still date-based rather than name-based, but your visitors will never know.

  • What I was doing is just some thinking and experimenting. I was sure it takes a lot more Flatpress knowledge than I have.

    What about a different approach? Static Page Tags. Everything remains the same, static pages are kept in the same folder, URLs doesn’t change, but… let’s assign tags to static pages, just like we do with the Tags plugin. Only changes are:
    1. the admin page lists only the static pages wearing the selected tags;
    2. on the static write page, there is a tag editor (like on the entry write page with the Tags plugin), or there is a different page to manage tags.
    With this system, the owner has a better view on his/her static pages, but nothing else changes.
Start a New Discussion

Howdy, Stranger!

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

In this Discussion