Mike Rockett
-
Posts
1,446 -
Joined
-
Last visited
-
Days Won
9
Everything posted by Mike Rockett
-
Module has been moved to GitLab. https://gitlab.com/rockettpw/tools/parsedown-extra-plugin
-
I've released 1.5.50, now hosted over at GitLab: https://gitlab.com/rockettpw/seo/jumplinks-one This release fixes an issue where calls to sitemap.xml from my sitemap module were being logged as 404s.
-
@Nick Belane – I've pushed JL 1.5.50, which should resolve the logging issue. I see there was already a check for the other sitemap module, just never accounted for my own after it was released.
-
@adrian So if I use include=hidden (I won't use all as it includes too much), I also need to exclude anything under admin, which is cool and it works, but it would mean that if a hidden parent would need to be excluded using the sitemap options. With that said, including hidden and unpublished pages will be configurable as a single config option. Root … Hidden Page (would be included by default if the option is enabled, so it would need to be turned off in options) Child 1 (included) Child 2 (included) … Would this be suitable? PS, I had hell with the File Compiler - not sure if anything there has changed of late, but my traits were just not being read properly. Any changes I made didn't take effect, even after clearing the cache. For now, I'm moving everything into the main module file except for the field builder.
-
Hi guys, super sorry for the delay here. @adrian – Will have a look at this now. Would likely want it to be configurable as well. @Nick Belane – I recall noticing this as well. My initial thinking was to ignore it as the plan was to drop the 404 tab in Jumplinks and replace it with a dedicated module that works side-by-side with Jumplinks v2. That said, I just don't have the time. Haven't even managed to get around to finishing the new Jumplinks. So for the time being, I'm going to see what I can do to have the sitemap ignored from the logger.
-
@panx Thanks for the report – please could you have a look in your server logs to see what the error is?
-
@rareyush My apologies for the late response here. Haven't had a chance to look into it yet. What is the domain of the new site? Is it live at the moment? Thinking I'd need to take a look and see what happens - if you could provide some more info. Thanks!
-
@rareyush Thanks — trying to find time to look into this, but have been very busy lately. The only thing I can think of is that your network or ISP is somehow disallowing access to that domain... But that’s just me thinking off the bat.
-
@rareyush - what is the legacy domain you have set in the module’s config?
-
@rareyush — Thanks! looks like I'll need to do some checking there, or maybe I should use curl. Will open an issue for this and try sort it out today.
-
@elabx Were you not redirected to the new docs site when trying the old URL https://rockett.pw/jumplinks?
-
I've updated in the modules directory. Don't have time at the moment to look at this – if its needed urgently, please submit a merge request. ?
-
The module has been moved to GitLab: https://gitlab.com/rockettpw/seo/markup-sitemap I have tagged 0.4.1-RC3, but have not yet updated it in the modules directory. Need to fire up the old laptop to get credentials for that.
-
Hey @adrian - thanks for pointing this out. Both are valid points, so I'll try look into it this weekend.
-
Hi @mel47 Seems odd as the vendor directory is included, and autoloaded. I'll need to take a look at this, but I'm afraid I'll only have time to do so this coming weekend. I'll open up an issue on Git in the meantime. Which version of PW are you running?
-
Thanks @Robin S, I'll give that a try.
-
@rash You're quite right. I did think about it earlier, but not 100% sure how to go about it... Would be awesome if we could do something like find('extends=FieldtypeImage').
-
I've bumped to 0.4.0 RC3 on the repo.
-
@rash Great, I figured it might be that. I'll push the change and bump as soon as I can.
-
@rash, the module checks to see if any image fields are available to your installation. To be more precise, the check is specific to FieldtypeImage, which might be where the problem is coming in... I'm not sure if there are other Image modules that extend FieldtypeImage out there (and if so, if you're using one). On my side though, a fresh install of PW with the latest MarkupSitemap and an image field added in results in the config showing the applicable selector:
-
Hi @rash -- did you add the image field in via the module's config? This is basically a way to globally add specific image fields in one swoop, and then the exclusion options are available at page-level to override.
-
No problem, and thanks. I'm going to stick with my original solution as I need it to only be set once... This also gives a level of customisation, which I like. ?
-
@ngrmm - if you're wanting to redirect /old-dir/* to /new/*, then you can use the following: Source: old-dir/{all} Destination: new/{all} {all} is a smart wildcard (https://rockett.pw/jumplinks/smart-wildcards) that equates to {all:all}, which matches anything and everything, until another wildcard or marker. So, /old-dir/child-a/ will be redirected to /new/child-a/. If you need the path after /new/ to be omitted, then just use new/ as the destination, and then /old-dir/child-a/ will redirect to /new/.
-
In all honesty, I think that Jumplinks is better suited to site migrations. Black holes should either be covered by a specifically-built module, or by htaccess/vhost config...
- 27 replies
-
- 2
-
-
-
- antispiders
- anticrawler
- (and 2 more)
-
Thanks Macrura I actually see that I'm going to need to bump PHP Typography to 6.x first, which means I'll land up bumping the module version to 0.5 for a little testing. Looks like there's been a cleanup and some new features added, as well as a bunch of hyphenation languages. Will open an issue for that shortly.
