So I'm anticipating a large number of pages on my site, and it would be good if I could create subdirectories for them. So, for example, for movie reviews, I'd like to create a subdirectory in _pages entitled MR. Then, I could store the MRs under there.
Tried it, but three problems:
a. File manager can't see the page (not really a problem, though, I don't care if it can see it);
b. Pointing to it through the index file like other pages by adding subdirectories to the reference URL such as "http://www.polywogg.ca/index.php/"MR/MRxxxxxxxx_-_title.php"" (i.e. adding the directory between index and the page name) tells me the file MRMRxxxxxxxx_-_title.php doesn't exist but I can create it ... it strips out the subdirectory slash;
c. Trying to go directly to the page (http://www.polywogg.ca/data/_pages/MR/MRxxxxxxxx_-_title.php) gives me a "Not an entry point" error.
I'm going to have far too many pages to just put in one directory, but not sure how to get around this. Really need an option on this before I go any further.
Not sure how that is going to work.
a. File manager can't see the page (not really a problem, though, I don't care if it can see it);
If the File Manager can't see the page, then it's not going to be a part of your gpEasy installation. The only way to add a page to gpEasy is through the file manager.
Are you wanting to add pages without them showing up in the menus on your site?
Hmm...I never thought of a solution as being able to "hide" from the menus. Interesting.
Here's the issue in a nutshell...I intend on having about 1500 movie reviews, about same number of book reviews, all within about a year. If I do them all in the same directory, I see two potential problems:
a. I've heard there are performance slowdowns if you have too many files in the same directory -- mine could be near 3000 pages within the year; and,
b. the filemanager is going to be REALLY unwieldy if I see them all at the same time.
On a normal HTML-based website, and a lot of other CMS, you can create:
www.domain.com/books/br01.htm, br02.htm, br03.htm
www.domain.com/movies/mr01.htm, mr02.htm, mr03.htm
So the files are grouped.
Since we already seem to have some grouping options like "SPECIAL" pages, I was hoping for a filetype (potentially) that would allow me to have sub-pages in a sub-directory, or several sub-directories (like MR0001_to_1000, MR1001_to_2000, etc.).
But if you think the performance issues are neglible (since you never actually go into the pages directory except on direct reference), and I could "hide" the sub-pages so they don't show up on file manager unless I specifically want to see them (i.e. I might still need to edit from time to time, so I would still need to have an option to access them somehow), I'd be fine with that solution.
Or any other solution you might have! :-) I'm soooo close to being able to roll-out fully...
3000 pages per year is a lot of pages. I hate to say it, but I'm not sure gpEasy is the right program for your project.
As you mentioned, (a) 3000 files in a folder reduces performance and (b) the File Manager will become unwieldingly large.
There is the potential to create a filetype that could handle these needs, but it would require some custom coding to make it work.
For clarity, it wouldn't be 3000/year, just 3000 in the first year as I clear out a backlog. But that's still a large number.
Before I give up on GPeasy though, as it meets so many of my other needs without overloading the server, I see a bunch of small options...
a. Is there any benefit to using the "FILE UPLOAD" area? Does that give me any options to store files there in sub-directories that wouldn't slowdown GPEASY's options? Or is that simply a "holding" area?
b. My preferred choice, if possible, would be to replicate the "SPECIAL_(filename)" taxonomy to create an equivalent of "DIRXXX_(filename)" or "DIRYYY_(filename)" taxonomy. But I don't know which files I should target for my custom re-coding...I guess if I put it differently, which GPEASY files generate separate treatment of "Special" files that I could try and generalize for a "directory" structure? Presumably you have some sort of if/else structure in one of them that says "if it's a normal page, pull it from here" but if it it's a "special page, do this instead". I was thinking I could add some sub-structure to that if/else/else/else structure to create refs for other directories.
c. My bigger option is to create a dynamic "single" page that would have to parse variables from the referring link ... for example, if I add variables to the referring page link (i.e. index.php?area=mr&fileid=0000001) and then add some PHP code to tell it to include info from a file called "../pages/mr/0000001.htm or .txt or .php", then GPEasy wouldn't have to "see" the sub-pages, they just have to see the single page ... but that single page would have to allow "include" commands one of two ways I think...first, I could tell it to just "embed" the PHP parsing commands within a standard GPEASY page; or second, I could put the PHP parsing commands in the middle of a custom template page. I'd have to make it a manual direct link to the dynamic page rather than just having Index.php open it directly, as I would have to add the variables to the link I guess. Definitely more complicated than the first two options, but if I could do it through a template somehow, it wouldn't "hack" the installation.
d. I guess another option would be to eat server space and install multiple sites of GPEASY to limit the "list" of seeable files for each file area to only that type...just replicate the basic install so all the templates etc are the same so it looks like one install, but GPEASY would treat it as 10 separate installs.
Any guidance would be appreciated! And I really appreciate all the advice and answers so far. I'm investing a bit of extra time up front in my needs analysis as I don't want to get 1000 pages down the road and realize I missed something I should have asked earlier!
I would say (b) or (c) would be your best options. At first glance, they seem pretty similar...
Take a look at /include/main.php and look for the switch() statement that determines if it's a 'special', 'admin' or regular page
$title = common::WhichPage();
$type = common::PageType($title);
$page = new special_display($title,$type);
The solution looks "straightforward":
case 'direct': include_once($rootDir.'/include/direct.php'); $page = new direct_display($title,$type); break;
So next step would be to create direct.php which would tell system how to process a page that was one directory farther down under "_pages" (essentially parsing the filename referencein $title into three parts -- the above ref would tell it that it was a "Directory" and therefore use direct.php); I could parse the next "piece" to find out the name of the directory (MRS, BRS, Recipe) to give it "multiple" options so that I could say "Direct_MRS_MR001" and "Direct_BRS_BR001" or "Direct_Recipe_REC001"; and parse the last bit to get the actual filename).
I could basically replicate Special.php file so that I would basically add a small subroutine at the top to change the path to the file (i.e. insert "directory" in the fileref that already exists for regular pages -- ../data/_pages/(directory)/filename).
And all of that is within or close to within my skillset. But I then realized two things going through the rest of MAIN.PHP...
a. I have no idea how to then go back to modify all the pagerefs for the regular filenames -- in a sense, figuring out how to call them normally so that the links off that direct.php would still work properly (they'd all be off by a directory level, and the level would be dynamically defined); and,
b. After I got it all working, the system still wouldn't SEE the files so I wouldn't be able to edit them afterwards (unless I somehow edit the admin page where it lists the file), I couldn't create new ones except manually, and the SEARCH gadget wouldn't search them.
If I can't get "b" to work, it's kind of pointless. And that level of modification is way beyond my skillset. I mention the solution up to where I got it simply in case others want to build off of it.
But I think for me I have four options:
a. Go with what's here and add pages until it explodes;
b. Change my sub-pages so that they are simple text or PDFs maybe that are just links from regular pages (i.e. like indices to other types of files that GP can't see) and accept that the search function won't see them (might be able to get a google search to search manually?).
c. Try installing multiple versions for every sub-category that I might have.
d. Abandon hope all ye who enter here and try doing a very simple site just in CSS and XHMTL without all the bells and whistles like comments etc.
e. Return to my original search for a lite CMS but with one that allows sub-directories.
Any suggestions for c or e would be greatly appreciated! :-)
And thanks for your help so far, even if I can't get it over the goalline!
Yeah, there's definitely a bit of coding that would have to happen to make this work. Wish I had more time to help you with it...
A couple of thoughts though. The use of subdirectories should only be on the server. Requests should all be /index.php/--page--. Otherwise the .css and .js files associated with your theme won't load for the user correctly.
http://exmple.com/index.php/Category_Subcategory_Item could pull data from a file on the server /data/_yourdir/Category/Subcategory/Item
It might actually be easiest to create an addon. That way you wouldn't have to change the core of gpEasy (Take a look at the code of the Simple Blog Plugin). Then Requests could be something like http://exmple.com/index.php/Special_Reviews?id=123 or http://exmple.com/index.php/Special_Reviews?id=Movie_Title.
Find out more about our Provider Spotlight