ℹ️
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
multiple content directories
  • Is it possible to have multiple content directories? I want to create a hierarchy like fp-content/content_a fp_content/content_b ... I don't mind writing a plugin to handle this type of functionality, (of course if one already existed, that would be great, but I didn't find anything even close) I would appreciate some pointers on where to start, or what to model it after. Thanks in advance, dave
  • I've been thinking about that myself, but it's not so easy; first FP_CONTENT is a constant in /defaults.php, and, as such, you can't redefine it at runtime; no big deal, you could define a variable and then define the constant, but of course, a plugin wouldn't be enough. and then, again, CONFIG_DIR is usually inside FP_CONTENT, so you either set it to another dir or you have to think it well... so I momentarily set the idea aside; if you have time to fiddle with a plugin/addon/patch feel free to do it! someone did come up with a solution for multiple instances w/ one codebase, though: http://flatpress.org/vanilla2/discussion/comment/5488/# have fun!
  • Thanks for the reply. And yes, I had already seen that discussion, but virtual hosts isn't quite what I had in mind. I am ok leaving FP_CONTENT, CONFIG_DIR and most of the vars/defines based on FP_CONTENT alone. The one I think I need to work with is CONTENT_DIR. Would a hierarchy like fp_content/content/dir_a fp_content/content/dir_b ... be more feasible? In this organization there would be no entries in 'content', all entries would be in either dir_a, dir_b, ... I assume the hierarchy walker would have no problem finding entries one more level deep in the filesystem. A possible problem is how the user specifies which sub-directory below 'content' to use when adding a new entry. Time to start digging in to the code.
  • in this case, don't forget the index would be still affected as well
  • Ah yes, the index. Kind of the heart (or brains, or GPS) of FP. Now that I've delved a little deeper, which of these options do you think would be easier? 1. Keep the index in FP_CONTENT, and expand it to contain a 'directory' element (much like the 'strings' element)? or 2. Move the index down one level into dir_a, (and dir_b, ...) and iterate through multiple BPlusTrees? or 3. some other method I haven't thought of yet?
  • I would group together content/ and index/ in their respective content_*/ parent directory you could then remove the CONTENT_DIR and INDEX_DIR from /defaults.php and set them programmatically from within the plugin. you might have to refactor things a bit (e.g. re-order when system functions are called) by the way, if you don't mind changing themes and other settings for each of your content_* directory, why not to use plain old categories? A well-thought category tree would be enough. e.g.: Content A : 1 --other cat: 10 --another cat : 11 Content B: 2 --other cat : 20 Content C: 3 --other cats: 30 Plugins such 'archives' and 'categories' can be then rewritten/modified to suit the category choice and hide the other 'root' categories. IMO multiple content dirs are more useful if you can choose the entire FP_CONTENT dir, so that you have many independent blogs, with only one codebase (much easier to upgrade)
  • > by the way, if you don't mind changing themes and other settings for each of your > content_* directory, why not to use plain old categories? A good question. The OS I am trying to run this on (STOP 7 from BAE Systems) is more than a typical *nix OS. This OS has security labels (Unclassified, Confidential, Secret, ...) applied to each filesystem object, and to each process. The OS decides which process can access which objects. So I want to have my different content directories to have different labels. When my webserver runs at Unclassified it can only read the Unclassified content, but when the webserver runs at Confidential, it can read both the Confidential and Unclassified content. Using the OS to do the policy enforcement, instead of FP doing the separation based on categories is more trust worthy. It looks like I am headed down the path of an 'index' in each content directory, mostly because the index needs to be writable by the process adding entries. What else needs to be writable? the cache (of course), does anything in fp-content/config get updated as part of adding/commenting on entries? Assume an admin will do the initial setup and so can write to everything.
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!

In this Discussion