archived MarkupSitemap

[Mike Rockett]

17 minutes ago, Mike Rockett said:

Now that I think about it, we do actually need a way to set the iso for sites that do not use a home page name for the default language.

Okay, I've set it up to use a custom ISO configuration option for the default language. It only works when the home page's default language name is empty (which is "home" when processed) and LanguageSupportPageName's useHomeSegment is set to false.

Output:

    <url>
        <loc>http://pw-modules.local/</loc>
        <lastmod>2017-09-15T18:41:07+02:00</lastmod>
        <xhtml:link rel="alternate" hreflang="en" href="http://pw-modules.local/"/>
        <xhtml:link rel="alternate" hreflang="de" href="http://pw-modules.local/de/"/>
        <xhtml:link rel="alternate" hreflang="fi" href="http://pw-modules.local/fi/"/>
    </url>
    <url>
        <loc>http://pw-modules.local/de/</loc>
        <lastmod>2017-09-15T18:41:07+02:00</lastmod>
        <xhtml:link rel="alternate" hreflang="en" href="http://pw-modules.local/"/>
        <xhtml:link rel="alternate" hreflang="de" href="http://pw-modules.local/de/"/>
        <xhtml:link rel="alternate" hreflang="fi" href="http://pw-modules.local/fi/"/>
    </url>
    <url>
        <loc>http://pw-modules.local/fi/</loc>
        <lastmod>2017-09-15T18:41:07+02:00</lastmod>
        <xhtml:link rel="alternate" hreflang="en" href="http://pw-modules.local/"/>
        <xhtml:link rel="alternate" hreflang="de" href="http://pw-modules.local/de/"/>
        <xhtml:link rel="alternate" hreflang="fi" href="http://pw-modules.local/fi/"/>
    </url>
    <url>
        <loc>http://pw-modules.local/about/</loc>
        <lastmod>2017-09-15T17:57:17+02:00</lastmod>
        <xhtml:link rel="alternate" hreflang="en" href="http://pw-modules.local/about/"/>
        <xhtml:link rel="alternate" hreflang="de" href="http://pw-modules.local/de/uber/"/>
        <xhtml:link rel="alternate" hreflang="fi" href="http://pw-modules.local/fi/tietoja/"/>
    </url>
    <url>
        <loc>http://pw-modules.local/de/uber/</loc>
        <lastmod>2017-09-15T17:57:17+02:00</lastmod>
        <xhtml:link rel="alternate" hreflang="en" href="http://pw-modules.local/about/"/>
        <xhtml:link rel="alternate" hreflang="de" href="http://pw-modules.local/de/uber/"/>
        <xhtml:link rel="alternate" hreflang="fi" href="http://pw-modules.local/fi/tietoja/"/>
    </url>
    <url>
        <loc>http://pw-modules.local/fi/tietoja/</loc>
        <lastmod>2017-09-15T17:57:17+02:00</lastmod>
        <xhtml:link rel="alternate" hreflang="en" href="http://pw-modules.local/about/"/>
        <xhtml:link rel="alternate" hreflang="de" href="http://pw-modules.local/de/uber/"/>
        <xhtml:link rel="alternate" hreflang="fi" href="http://pw-modules.local/fi/tietoja/"/>
    </url>

 

[Mike Rockett]

I've pushed 0.2.0-beta to Github: https://github.com/rockettpw/markup-sitemap/. Will update the modules directory shortly.

Please test and let me know what else might need to be attended to.

[maxf5]

8 hours ago, Mike Rockett said:

Home Page default language name

 

Hi @Mike Rockett, i knew that "trick". But i don't want my default language urls (german/de) look like: sample.de/de/contact,
or is there any option to remove that url segment of the default language in the url when having a default language name in "Home > Settings"?

 

EDIT: Ah forget it, i just updated the module to version 0.20 and saw "ISO code for default language" 

[Mike Rockett]

Bumped to 0.2.2-beta:

• Explicitly requires PW 3+ and PHP 5.6+
• Fixes a namespace issue that broke install and uninstall routines

I'd very much appreciate it if everyone who would like to use MarkupSitemap tests it and provides some feedback. By the looks of it, this can be pushed to stable 1.0.0 soon, unless any other bugs come up... Thanks!

[Mike Rockett]

Bumped to 0.2.3-beta:

• Adds support for ProcessWire 2.8
• Rolls back previous fix in favour of the FileCompiler doing its thing

[Mike Rockett]

Bumped to 0.2.4-beta:

• Fixes schema changes (per ThePixelDeveloper's recent commits). Note that the sitemap doesn't render using the XML viewer, and it's still to be tested in Search Console.
• A few changes to ModuleConfig. Adding image fields to the sitemap is now only possible if your site contains image fields.
• Hook priority is changed (from after to before). This is mostly due to SystemNotifications showing a 404 for the sitemap.xml route.
• add X-SitemapRetrievedFromCache header for debugging purposes.

PS, I'm working on a new docs site as well. It'll be powered by PW, and will have docs for all my modules.

On a separate note: Jumplinks is on the mantleshelf for a little while as I'd like to do a refactor to make the code a little more 'lean' and my schedule is not what it once was. There are a few things bugging me with regards to the way it's put together at the moment, and it feels a little chunky. Sorry for the delay on that one, guys...

[backes]

Hey there,

tried to install the module this evening, but got the following error at the installation:

Error: Uncaught Error: Class 'Field' not found in /site/modules/MarkupSitemap/src/Utilities/Fields.php:49
Stack trace:
#0 site/modules/MarkupSitemap/MarkupSitemap.module.php(90): MarkupSitemap->createField('FieldsetOpen', 'sitemap_fieldse...', Array, true)
#1 wire/core/Wire.php(380): MarkupSitemap->___install()
#2 wire/core/WireHooks.php(698): ProcessWire\Wire->_callMethod('___install', Array)
#3 wire/core/Wire.php(442): ProcessWire\WireHooks->runHooks(Object(MarkupSitemap), 'install', Array)
#4 wire/core/Modules.php(1688): ProcessWire\Wire->__call('install', Array)
#5 wire/core/Wire.php(386): ProcessWire\Modules->___install('MarkupSitemap', Array)
#6 /www/htdocs (line 49 of site/modules/MarkupSitemap/src/Utilities/Fields.php) 

This error message was shown because: you are logged in as a Superuser. Error has been logged.

I'm running the 3.0.77 dev branch!

Thanks for the great module, by the way! 

[Mike Rockett]

@backes - I see... For some reason, it was working on my side. Was trying to add suport for ProcessWire 2.8, and it did appear to work in 3.0. As you are using PW3, please change the reference in Fields.php to the following:

$field = new \ProcessWire\Field();

This is at https://github.com/rockettpw/markup-sitemap/blob/master/src/Utilities/Fields.php#L49

I would change it myself, but am making considerable changes to the module at the moment, whereby the fields don't actually get installed, but rather appened to the page editor when it loads, and then saved to module config, instead of each page. This keeps everything centralised. Work commitments at the moment, so will get back to this in about a week.

[Mike Rockett]

Bumped to 0.3.0-beta:

This release makes considerable changes to the way in which the module works. Here's the breakdown of notable changes in this release:

No more page fields

Instead of using actual attached fields on a page-by-page basis, the module now saves related data in a centralised manner to its own configuration, and page fields are built on the fly when needed.

This means that, when a template is defined in the module's config to use sitemap options and is later removed from the list, sitemap options for affected pages are not removed. Should the template be added to the list at a later stage, all saved options for pages belonging to that template are 'restored', simply meaning that the module will refer to them during the build process.

The only time sitemap options for a page are removed is when either the page in question is deleted after having been trashed, or when the module is uninstalled (everything gets deleted, in this case).

Stylesheet

Due to a bug in Chrome (and possibly other browsers, though untested), the stylesheet is now turned on by default. Further, small aesthetic changes were made to the stylesheet, and a bug regarding the priority column was fixed.

Commit da42cb7 changelog:

• alter stylesheet
• use separate class-loader
• separate methods to traits
• bind options to module-config, instead of page-fields
• use stylesheet by default
• add debug trait
• remove gitignore stuff we don't need

Requirements

The module now requires at least ProcessWire 2.8.16+ or 3.0.16+, due to the use of saveConfig and getConfig.

Upgrade notes

As the module is in Beta, there is no upgrade path. You will need to uninstall Sitemap before installing it again if you would like to remove the redundant system fields. If it doesn't matter, then a normal upgrade will do fine.

[Mike Rockett]

Bumped to 0.3.1 Beta - RC1:

• Corrects PW version check
• Ignore options when not set by template
• Fix instanceof Pageimage references

This is a new release candidate. Please test.

https://github.com/rockettpw/markup-sitemap/

[Mike Rockett]

Just pushed RC2 - was not checking the PW version properly (it requires either 2.8.16 or 3.0.16 to run).

Speaking of PW versioning: Not sure if this has been brought up before (please point me to it if it has), but how will the legacy version be bumped when we reach PW 3.1? Would be unwise to make it 2.9 because, when we reach 3.2, legacy would logically need to be 3.0. Perhaps there are plans to drop legacy?

[backes]

Hey @Mike Rockett,

had some days off, so now back at the laptop and checking it out.

Seems to work fine now in the 0.3.2 version! Thank you!

Martin

[backes]

Hello again,

is there a way to add hidden pages to the Sitemap? I'm used to make some hidden pages for several not so important pages.

Thanks, Martin

[Mike Rockett]

14 minutes ago, backes said:

Hello again,

is there a way to add hidden pages to the Sitemap? I'm used to make some hidden pages for several not so important pages.

Thanks, Martin

I'd probably need to include a selector-toggle for that - perhaps a simple option in the module's configuration that allows for the inclusion of hidden pages. With that said, I do discourage it. If a page is meant to be hidden, then it shouldn't be shown, no? What exactly are you hiding your pages from?

[backes]

Currently I'm using the hidden/not hidden for navigation purposes. For example, the not hidden pages will be rendered in the primary navigation and the hidden stuff goes with specific page calls in several meta navigations.

Or do you have any better workflow for the page structuring, that's also understandable by clients?

[Mike Rockett]

6 hours ago, backes said:

Currently I'm using the hidden/not hidden for navigation purposes. For example, the not hidden pages will be rendered in the primary navigation and the hidden stuff goes with specific page calls in several meta navigations.

Or do you have any better workflow for the page structuring, that's also understandable by clients?

I'd be inclined to use Menu Builder in that case, in terms of seperation of your menus, if that's what this is about. To me, I feel that setting page visibility just for the purposes of menus is a tad overkill (keep in mind that I've never had to hide a page from lists and searches before). That said, your structure could be very specific, and I may be missing something here...

[backes]

Good point. I'll try to use the MenuBuilder in my current project. It looks promising, so I don't have to tell clients, what to hide and what not!

Thanks for this tip!

[Mike Rockett]

5 minutes ago, backes said:

Thanks for this tip!

You're welcome! Hope it goes well.

[Guy Verville]

Hi Mike,

Thank you for your excellent module. A wish : we have a big website where product pages are stored under a parent (a series =>  parent: series-carpet, children: sku-carpet, this is handy for our client to see the SKUs associated to a collection). These children are not hidden for search purpose, but are hidden from the navigation and, hence, from search engines. Your module generates for that site a 10000 sitemap list because the children are included. We can't go from series to series to disallow the sitemap generation for the children.

In other words. Your module allows us to include/exclude sitemap generation for actual pages. It would be very convenient to disallow/allow a sitemap for a whole template from the template settings.

[Mike Rockett]

@Guy Verville - Sorry for the delay in responding. I’ll look into this for you – should be easy enough to achieve.

[Mike Rockett]

@Guy Verville – It looks like the template process doesn’t give me as much flexibility that the page edit process does. As such, I think I’ll dump this the module config. Truthfully, I actually think it’ll be better this way.

Edit: I’ve bumped to 0.3.3 RC2.2:

You can now exlude templates via the config page. If templates are included (for sitemap options) via config, those inclusions will simply be ignored (non-destructive so that restoring access is simple).

Please let me know if this works smoothly for you.

Related commit: https://github.com/rockettpw/markup-sitemap/commit/4981b9b537bce556ba15d4eacac0d095fea170da

[Guy Verville]

Thank you very much for this nice addition! I will give it to my programmer (he had created his own solution inspired by your module and tightly integrated wit the existing code, but your config approach is more convenient and will certainly help a lot of people here).

PS: I have installed in my modest and personal website and works like a charm. http://www.guyverville.com/sitemap.xml

[Mike Rockett]

@Guy Verville

Glad to know it works smoothly for your personal site. Let me know if any issues arise, and I’ll be happy to help.

[Mike Rockett]

I'd like to get some general feedback from people using the module. If you have a minute, please share your experiences or issues (even those that are self-resolved, if any). If it's looking stable enough, I'd like to bump to stable v1. If there are issues, please also feel free to let me know. Thanks!

[maxf5]

I am using the module on various multilingual sites and it's working fine!

When you have Jumplinks installed it sometimes hits an 404 on /sitemap.xml even though the link/sitemap is working.
Do you have to create an extra page and template  (xml header) for it?