Category for all CMS Pages

[oim37]

Hello,

Module have settings for category :

• All static pages
• All blog pages

But i not found option (all cms pages) I found only for 1 cms page, but i have ~700 cms pages (every page have 5 languages) and in output in must be ~3500 pages. How it make auto generated all in sitemap.xml?

[mjauvin]

Do you actually have 700 different pages or do you mean the same page with different parameters?

[oim37]

700 page files. Each file contains a description of the domain zone, they are generally similar to everything, and it is convenient to translate them, several parameters change, for example, the country, and several other parameters. 700 files with domains zone descriptions (domain-ae.htm, domain-fr.htm etc 700 files.) This scheme allows to conveniently add new pages and add a language variable.

And the page is - cms page, because each of them pulls up the price for each domain zone from the billing. Task to add all this pages to sitemap.xml on all languages.

[mjauvin]

The way this is usually done is to have a translatable model with fields that you can fill in the backend, then you create a SINGLE CMS page that has a parameter for the model slug or id which is retrieved from db and its values/fields are used in the twig markup.

[oim37]

I understand, just change the model, but in another way, can i add some kind of parameter so that they are taken into sitemap.xml automatically?

[mjauvin]

You'd have to add a new menu item type in your plugin, we certainly won't add this to Sitemap plugin.

[oim37]

Thank you for the clarification.

[LukeTowers]

@oim37 I'm not necessarily opposed to adding an item for "All CMS Pages", but it seems like it would only be necessary for your specific use case, a use case which might be better served by being structured a bit differently (although I don't really have enough information to provide any recommendations at the moment).

If you would like to register it for yourself however you should be able to do the following:

use BackendAuth;
use Cms\Classes\Controller as CmsController;
use Cms\Classes\Page as CmsPage;
use Cms\Classes\Theme;
use System\Classes\PluginBase;

class MyPlugin extends PluginBase
{
    public function boot()
    {
        $this->registerMenuItemTypes();
    }

    /**
     * Register the frontend Menu Item types provided by this plugin
     */
    protected function registerMenuItemTypes(): void
    {
        Event::listen('pages.menuitem.listTypes', function () {
            return [
                'all-cms-pages' => 'All CMS Pages'
            ];
        });

        Event::listen('pages.menuitem.getTypeInfo', function ($type) {
            if ($type === 'all-cms-pages') {
                return [
                    'dynamicItems' => true
                ];
            }
        });

        Event::listen('pages.menuitem.resolveItem', function ($type, $item, $url, $theme) {
            if ($type === 'all-cms-pages') {
                $result = [];
                $pages = CmsPage::listInTheme(Theme::getActiveTheme(), true);
                $controller = CmsController::getController() ?: new CmsController;
                foreach ($pages as $page) {
                    // Remove hidden CMS pages from menus when backend user is logged out
                    if ($page->is_hidden && !BackendAuth::getUser()) {
                        continue;
                    }

                    $pageUrl = $controller->pageUrl($page->getFileName(), [], false);
                    $result[] = [
                        'url' => $pageUrl,
                        'isActive' => rtrim(pageUrl, '/') === rtrim($url, '/'),
                        'mtime' => $page->mtime ?: null,
                    ];
                }
            }
        });
    }
}

NOTE: This is completely untested / not even run once code, but in theory it should get the job done.

[LukeTowers]

The reason why it doesn't already exist and why I'm hesitant to add it is because CMS pages are by their very nature intended to be highly dynamic and reliant on URL parameters to affect the final suite of URLs that are handled by them.

If you are using CMS pages in a scheme where 1 CMS page = 1 URL with no parameters of any kind, then you're most likely better served by using static pages for that. And if you're using hundreds of CMS pages that are mostly the same just with separate static URLs then you would most likely be better served by some combination of the translate plugin and / or custom components that you would then register your own menu item type to handle generating URLs for, just like the Blog plugin does for the All Blog Posts or All Blog Categories menu item types (supported by a single CMS page).

Let me know if you have any questions @oim37!

[oim37]

I choose for this task - CMS page because it fast and simple for start, all countries use a code to pull up prices from a third-party system and some pages - about 250 domains by country have different registration conditions and contain more fields than international domains. Thus, there is no understanding yet to conveniently automate all this.

Information on them rarely changes, quite convenient. For the sitemap I use an external free service, but it is free up to 5000 pages, and I already have ~ 4700, so I decided to try the module.

I use blog for news. ~ 100 Static pages for all other content ~ 1100 CMS ~ 3500 for domain pages. - This on 5 languages. (files ~700)

Example of creating a new page now: cp domain-aw.htm domain-sn.htm sed -i 's/aw/sn/g' domain-sn.htm sed -i 's/aruba/senegal/g' domain-sn.htm

And if i need to add new field - i edit file. If all this is automated into 1 file, then I will still need to edit it there, the benefit of automation is not obvious.

I tried to add this code in a new plugin, apparently I'm doing something wrong or I need to add code in sitemap plugin.

Thanks anyway for the answer.

[LukeTowers]

@oim37 this code would go into a new plugin, and you would ensure that it requires Winter.Sitemap.

What issues are you having with the code? In theory it should work.