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.

This could be a good candidate for Jumplinks 2.

@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.

Whilst we're on the topic of processors, I've switched over to Stylus completely. The only time I use Sass and Less is when a framework requires it. I've becomed so accustomed to the way stylus works, that if you asked me to type out some Sass, Less, or CSS, you'd find missing colons everywhere.

@MindFull The htaccess file does allow access to the directory: # ----------------------------------------------------------------------------------------------- # 12. Access Restrictions: Keep web users out of dirs that begin with a period, # but let services like Lets Encrypt use the webroot authentication method. # ----------------------------------------------------------------------------------------------- RewriteRule "(^|/)\.(?!well-known)" - [F]

Looks awesome! Though, it appears that, when I use a custom logo, a CSS filter makes it white. (filter: brightness(0) invert(1);) (Edit: issue opened)

Was thinking of doing something like this the other day, but couldn't find the time. I might still get into it soon - you never know. Nice to see it outside of my imagination. ;-)

I like it too. I generally mix and match, and often give clients the option. I wonder if we should have a variant of Reno with a top-nav...

Ah, you're quite right - was one of my sites that hasn't upgraded yet (missed it!). Thanks

Hi @tpr - there also seems to be an issue with the Reno tweaks. When guest is using Reno, for the login, and I've turned on the fixed header, the "Login" header is offset by the width of the sidebar, which does not exist on the login screen, so it just has an empty space to the left.

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...

@Rudy - At this point, it's just me, so gitlab.com is perfect for private repos. Thanks for the tip though - it is a good idea.

Bumped to 0.2.3-beta: Adds support for ProcessWire 2.8 Rolls back previous fix in favour of the FileCompiler doing its thing

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!

@clsource - Indeed, thanks. I saw that mirror feature - it really is great. Nonetheless, going to stick to my plan as mentioned above for the time being.

Thanks - I have heard of them before, but didn't like it much (those years back). Will check it out again soon.

Thanks. I think they've made quite a bit of improvement on the performance front. I've only really tested on the web side of things, and haven't actually done anything console-related yet. The interface they're using at the moment takes a while to get used to, and I see it's gone through several iterations over the years. For me, changes like that can be very distracting. I do like the avatars feature as well, though I wonder how popular it is. Having given this a little thought, I think I'll stick to GH for the time being, and will simply use GL for private repos (only needed for backup purposes, really).

I've been pondering on this for a while now. GL has a much bigger feature-set than GH, and allows private repos for free. Much of the work I do doesn't warrant the use of many of the features, but there are a couple of other thinks I like, like sub-groups and, of course, private repos. Curious to know who in the PW community is actively using it, other than Bernhard, and what everyone thinks about it. I'm thinking of switching, and am currently testing everything out. I think my biggest concern is that folks use GH more than GL, and so opening issues on my repos would require a GL account, which some may not want to do...

@chrisbourn: Are you using ProcessWire? There should be much more than that if you are using it... Just checking. Perhaps htaccess is not enabled with your host?

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.

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>

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.

Indeed it is - and I bumped into how it works by accident. Will be sticking to this method. v0.2 coming out shortly.

Just to add to this point, @maxf5's issue can be solved by adding a default-language name to the home page. In LanguageSupportPageNames, the default language URI is the same as it would be without a language, and so it won't show even if the name is set. Here's the setup I'm using on the built-in language profile: LanguageSupportPageNames Home Page default language name Sitemap url output <url> <loc>http://pw-modules.local/</loc> <lastmod>2017-09-15T15:35:15+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>

This module family appears to work fine on PW3 (sans Macura's issue above). @netcarver, please could you tag it in the modules directory to show that it does indeed work?