Lets dump .php pages files

[crnogorac081]

I am thinking about ways to improve wb, and one of them is to finaly dump phisical .php files in pages.

So if we have real urls structure like

1. /home
2. /form
3. /about
4. /news_page
5. /news_page/post-1
6. /news_page/post-2
..etc

That means all pages must be in DB _pages table, including ones that are News post. So single post from News must be inserted as db entry in _pages table.

On page create (add/update) page, variable $page_id or others should be created and inserted in new or other field in _pages table. Lets call it "page_data"

Code: [Select]


// 1. On Page created make array (same variables as in created .php file)

// for pages like code/wysiwyg/form/ news-group etc
$aPageData = [
  'page_id' => 2,
];
// or for news single post
$aPageData = [
  'page_id' => 2,
  'section_id' => 3,
  'post_id' => 4,
  'post_section' => 5
];

$sPageData = serialize($aPageData);
// Save to DB in 'page_data'

// 2. On page view, get data from DB

$link = '/page-url'
$oPages= $database->query("SELECT * FROM `".TABLE_PREFIX."pages` WHERE `link` = '$link' ");
if (!$oPages OR $oPages->numRows() == 0) {
// Error 404 Page
$page_id= 123; // redirect to 404 page
} else {
$aRow= $oPages ->fetchRow();
$aPageData = unserialize($aRow['page_data']);
$page_id = $aRow['page_id'];
}

foreach($aPageData as $key => $value)
    {
        $$key = $value;
    }
   
echo '  $page_id = '.$page_id;
echo ' , $section_id = '.$section_id;
echo ' , $post_id = '.$post_id;
echo ' , $post_section = '.$post_section;
// require('../index.php');

what do you think

[sternchen8875]

What would be the advantage of this method?
At best, a few milliseconds faster when loading the page. On the other hand, I lose the possibilities offered by modules such as News, OFA etc., e.g. a common overview. A full-text search would certainly be an advantage, but there are already ideas and it is only a question of programming whether I extend a search via a single DB table or via several from other modules. Again, in the end it's only milliseconds that a visitor doesn't notice.

[crnogorac081]

For start to dump .php files, i have instalation with 4000 pages on local machine, it Is 4000 useless node files + files under /posta

Which posibilities you think you will lose ?

[sternchen8875]

i have instalation with 4000 pages on local machine, it Is 4000 useless node files + files under /posta

i understand

Which posibilities you think you will lose ?

every module with own subpages has the posibility, to display a overview from all the item of this module, bakery, news, ofa etc. I think we lose this possibility of an overview if we save the complete content for each page in _pages. But maybe I don't really understand your point yet

Let's go into detail...
We are currently storing the page ID in _pages, then looking for the modules for this page ID in _sections in the order specified there. We then search for the contents section by section.
I don't know how this system is supposed to work if all content is already stored in the _pages. And if we only look at one module, for example the News with 4000 subpages, then you definitely need the access files under /posts, otherwise you will get invalid links or more general links.

But, as I said, maybe I'm misunderstanding your concern and you "just" want to have the news subpages in the _pages table instead of in _mod_news_posts. But that wouldn't change anything about the respective access file.
There is currently the option of having these subpages recreated for modules with their own subpages, such as News, OFA or Bakery (WB info window - Rebuild Access Files). So that after deleting news articles, the subpages under /pages/posts also disappear (if not already deleted). You can also delete content directly in the database and then rearrange the file system.

[crnogorac081]

I will test with all modules when I have time

[sternchen8875]

tip: search in your archive for modules with a file "WBReorg.php". Every module with this file has the possibility, to work with subpages and this file rebuilds the access-files, if you send the request for this in the wb-info-window.

i use it also in some private modules in different list's to build subpages for detailed information about a item, but i use a switch in the module settings (for every section), with or without subpages. "without" means, i display only a overview, item by item. "With subpages" means, every item has a "Read more"-Link
Works like OFA

[CodeALot]

I think it's a good idea, it will make a cleaner file- and database structure overall.

[crnogorac081]

What would be challenging is that we will need to deal with show_menu2  then too, because some time ago I was helping forum member here to make another sm2 function, because he has big site with like 3-4000 pages and it was challenging to me because I have similar project, and you can see how slow loading is here and this is all because it takes time to load menu.

I analyzed show_menu2 function and it checks menu item one by one: if page is visible, then if page is for registered viewers etc, and this is all few DB calls per menu item, so it would be much faster if menu function would work like this:

1. check if there is any page set for viewing groups and users (you can do this with 1 DB query and if these fields are empty for all pages dont check this anymore, or if there are fields populated for some pages put them in array for further check)

2. a new procedure where _pages table would have like column "active" with true/false - so when page is added (first section) make it false, and then when you finish go to Sections and Activate page (check if section is active and date is between publish start / end).  This would be much easier and faster for menu loading.