archived MarkupSitemap

[Mike Rockett]

New Maintainer Needed

Sitemap is in need of developer to take over the project. There are a few minor issues with it, but for the most part, most scenarios, it works, and it works well. However, I'm unable to commit to further development, and would appreciate it if someone could take it over. If you're interested, please send me a private message and we can take it from there. Thanks! ?

[sebr]

Hi

I'm using this module for the first time in a multilingual website.

In my home, language prefix are empty because I manage URL directly:

1. mydomain.fr for French
2. mydomain.com for English
3. mydomain.de for Deutsch

The the MarkupSitemap module rendered something like that for each page (on mydomain.fr), after set default language (in module settings) to "fr" :

<xhtml:link rel="alternate" hreflang="fr" href="https://mydomain.fr/"/>
<xhtml:link rel="alternate" hreflang="" href="https://mydomain.fr/"/>
<xhtml:link rel="alternate" hreflang="" href="https://mydomain.fr/"/>

But I would like to render :

<xhtml:link rel="alternate" hreflang="fr" href="https://mydomain.fr/"/>
<xhtml:link rel="alternate" hreflang="en" href="https://mydomain.com/"/>
<xhtml:link rel="alternate" hreflang="de" href="https://mydomain.de/"/>

I tried to use Hook like that :

wire()->addHookAfter(MarkupSitemap::getAdditionalPages, function ($event) {
    $page = $event->arguments(0);
    $language = $event->arguments(1);

    MarkupSitemap::applyLanguageSupportHooks();

    return [
        'url' => 'https://mydomain.fr/test',
        'fr' => [
            'url' => 'https://mydomain.fr/test',
        ],
		'en' => [
			'url' => 'https://mydomain.com/test',
		]
        'de' => [
            'url' => 'https://mydomain.de/test',
        ],
    ];
});

But the sitemap rendering is the same. How can use the Hook to set alternate language URL from pages ?

[PWaddict]

@Mike Rockett can you please change only 1 word in order to enable cache busting image urls?

On the file SupportsImages.php at the line 28 change the httpUrl to uppercase: HTTPURL

$locImage = new Image($image->HTTPURL);

With this change you will support both PW core's and ProCache cache busting.

[Mike Rockett]

@sebr Apologies for not responding sooner. I don't use PW anymore as my line of work is now in SaaS – as such, I can't really remember how everything works when it comes to multii language. I'll need to find some time to dig into this. If there's anyone around that could assist with a merge request, that'd be great too ?

@PWaddict I have never used ProCache, so not sure how that works… Are you 100% sure that using the uppercase getter will fallback accordingly if ProCache does not process it (the getter)? I don't want to break anyone’s site by rolling this change out…

[netcarver]

@sebr Hello. Could you try changing your hook code from this:

wire()->addHookAfter(MarkupSitemap::getAdditionalPages, function ($event) {

to this:

wire()->addHookAfter("MarkupSitemap::getAdditionalPages", function ($event) {

?

[PWaddict]

6 hours ago, Mike Rockett said:

I have never used ProCache, so not sure how that works… Are you 100% sure that using the uppercase getter will fallback accordingly if ProCache does not process it (the getter)? I don't want to break anyone’s site by rolling this change out…

Yes, I'm 100% sure. ProcessWire has 2 properties for cache-busting, URL & HTTPURL.

Taken from https://processwire.com/api/ref/pageimage/:

HTTPURL

string

Same as the cache-busting uppercase “URL” property, but includes scheme and hostname.

URL

string

Same as $url property but with browser cache busting query string appended.

Taken from https://processwire.com/blog/posts/pw-3.0.98-procache-buster/:

ProcessWire's file and image fields (represented by Pagefile and Pageimage objects) already have an uppercase URL property which always returns a cache-busting version of the file's URL. This is the case whether you've got ProCache installed or not. But in ProcessWire master 3.0.96 or newer, ProCache Buster updates that URL property to use ProCache's enhanced buster, rather than the one built-in to the core.

[sebr]

Hi @netcarver I tried with quotes and without but the result is the same : no effect...

 

[Mike Rockett]

@PWaddict 0.8.0 has been released with the selected change. Please let me know if you encounter any issues.

[Peter Knight]

Is there a way to output the sitemap as as sitemap.xml file?

[Robin S]

9 hours ago, Peter Knight said:

Is there a way to output the sitemap as as sitemap.xml file?

The module readme says:

Quote

After installation, the sitemap will immediately be made available at /sitemap.xml.

If you’re looking for a basic sitemap, there’s nothing more you need to do.

 

[bedak]

Got the following error message after upgrading MarkupSitemap from 0.8.0 to 0.8.1
using PW 3.0.191 with PHP 8.0.13

Quote

Schwerwiegender Fehler: Uncaught TypeError: MarkupSitemap::removeSitemapCache(): Return value must be of type bool, null returned in site/modules/MarkupSitemap/MarkupSitemap.module.php:257

This happens right after upgrading or if changing the Cache-options and saving the options-page. Any solutions?
Sorry, please move this topic to the Mike Rockett's MarkupSitemap forum...
bedak

[lpa]

I tried to install this module for the first time, but it gives me this error, when saving the settings:

Fatal Error: Uncaught TypeError: Return value of MarkupSitemap::removeSitemapCache() must be of the type bool, null returned in site/modules/MarkupSitemap/MarkupSitemap.module.php:257

And no sitemap.xml file is generated. 

[bedak]

3 hours ago, lpa said:

I tried to install this module for the first time, but it gives me this error, when saving the settings:

Fatal Error: Uncaught TypeError: Return value of MarkupSitemap::removeSitemapCache() must be of the type bool, null returned in site/modules/MarkupSitemap/MarkupSitemap.module.php:257

And no sitemap.xml file is generated. 

I get the same error after upgrading from v.0.8.0 to 0.8.1 (PW 3.0.191; PHP 8.0.13)

[patman]

On 1/2/2022 at 11:10 AM, lpa said:

I tried to install this module for the first time, but it gives me this error, when saving the settings:

Fatal Error: Uncaught TypeError: Return value of MarkupSitemap::removeSitemapCache() must be of the type bool, null returned in site/modules/MarkupSitemap/MarkupSitemap.module.php:257

And no sitemap.xml file is generated. 

This is an issue when no cache exists.

You can try to go to /site/modules/MarkupSitemap/MarkupSitemap.module.php and modify the start of the function (line 230) as follows:

...
  public function removeSitemapCache(): bool
  {
    // Cache settings
    $cacheKey = 'MarkupSitemap';
    $cacheMethod = $this->cache_method ?: 'MarkupCache';
    $removed = false; // by default nothing is removed

    // Attempt to fetch sitemap from cache
...

 

[lpa]

Yes, I found that out and it fixes the problem. But the next problem is that no sitemap.xml is generated and no options are shown in the templates settings for the sitemap. 

[bedak]

4 hours ago, patman said:

This is an issue when no cache exists.

You can try to go to /site/modules/MarkupSitemap/MarkupSitemap.module.php and modify the start of the function (line 230) as follows:

...
  public function removeSitemapCache(): bool
  {
    // Cache settings
    $cacheKey = 'MarkupSitemap';
    $cacheMethod = $this->cache_method ?: 'MarkupCache';
    $removed = false; // by default nothing is removed

    // Attempt to fetch sitemap from cache
...

 

Thanx patman, adding 'removed=false' fixed the problem (with PHP-8+). Sitemap is again generated as in v0.8.0

[lpa]

11 hours ago, lpa said:

Yes, I found that out and it fixes the problem. But the next problem is that no sitemap.xml is generated and no options are shown in the templates settings for the sitemap. 

Well, now it works. I was expecting a file to be generated in the root, but then I realised it is dynamic. When you access domain.com/sitemap.xml, it is generated on the fly. 

Now my only concern is if I check the "Include hidden or unpublished pages", are really all the hidden and unpublished pages included? If I have some pages hidden because they won't be in the main navigation, I would like those to be included in the sitemap. But never any unpublished pages. 

[patman]

Quote

Well, now it works. I was expecting a file to be generated in the root, but then I realised it is dynamic. When you access domain.com/sitemap.xml, it is generated on the fly. 

Yes, the sitemap is generated dynamically, there is no file that you can find, but of course you can call it. If you enable the stylesheet it is also quite readable.

Quote

Now my only concern is if I check the "Include hidden or unpublished pages", are really all the hidden and unpublished pages included? If I have some pages hidden because they won't be in the main navigation, I would like those to be included in the sitemap. But never any unpublished pages. 

From my understanding of the source code I would say that in contrast to what the option "Include hidden or unpublished pages" suggests, only hidden pages will be included. The option is called sitemap_include_hidden and adds include=hidden to the selector.

[Mike Rockett]

Hi guys, sorry about this – will push a fix up shortly.

[Mike Rockett]

Thanks for reporting – 0.8.2 has been tagged with the fix.

[patman]

Hi!

Does anyone else have the following issue?

I have the MarkupSitemap module install and it works but I still get my err404 page triggered. Anyone an idea why? I can call https://myserver.com/sitemap.xml and it renders I can also call it with http://. Still some search engines manage to trigger the error page. The log of $_SERVER["REQUEST_URI"] in such a case and shows "/sitemap.xml". How can that happen?

Thanks!

[Mike Rockett]

@patman Not sure how that's possible. The module simply hooks onto PWs page not found event to display the sitemap at that path. Not sure if something has changed in PW itself that might cause this to happen, or perhaps another module is somehow conflicting.

Is anyone else experiencing this?

[patman]

Hey @Mike Rockett!

I had a suspicion stemming from the behavior of the module, i.e. working but still triggering the err404 page.
Line 152 of MarkupSitemap.module.php uses $this->addHookAfter althought you are trying to cancle further hooks in line 220/221.

To me that means that first the err404 page is created and then replaced by the content of your module, but I think in case the path /sitemap.xml matches, your module should take control and everything else should only execute in case it is a different path (normal processing sequence). I just changed line 152 to "before" version like this:

$this->addHookBefore('ProcessPageView::pageNotFound', $this, 'render');

Since then I didn't have any issues anymore and it seems to work as intended. Not sure this fully correct as I didn't read all the necessary documentation. Nevertheless, it solves my issue and didn't seem to have any (negative) side effect.

Maybe with your know how you can confirm / comment / decline this solution?

Best regards!

[adrian]

Hi @Mike Rockett - not sure how this hasn't been reported before so it makes me wonder if I am missing something, but when using the "Templates without sitemap access" option, these exclusions are only applied to top level parent pages. To fix things, I added the in_array check to the $page->children loop, like this:

      // Check for children and include where possible.
      if ($page->hasChildren($selector)) {
        foreach ($page->children($selector) as $child) {
          if (in_array($child->template->name, $this->sitemap_exclude_templates)) {
            continue;
          }
          $this->addPagesFromRoot($child);
        }
      }

Does it make sense to include there?

[Mike Rockett]

Hey @adrian — surely it should be working as it's a recursive method-call that uses canBeIncluded to determine whether or not the template has access? I looked very briefly and that's the way I'm seeing it.

On another note: wow, I have not looked at my modules in a looong time ?