Mike Rockett
-
Posts
1,452 -
Joined
-
Last visited
-
Days Won
9
Everything posted by Mike Rockett
-
@adrian – I've released 1.5.64 which adds the safety net around CLI usage (as a general rule) and request_uri. Please let me know if that solves it.
-
Guessing this should do the trick…?
-
@adrian The only thing I can think of is an upgrade to PHP 8.1, as that's the only thing that can cause it. I guess I'd need to find a way to have the module not do anything when being executed via the CLI...
-
Hi @adrian – very odd as $_SERVER['REQUEST_URI'] should never be null. Perhaps something is unsetting it? Imo, Jumplinks should actually be throwing a hard exception in this case.
-
Thanks – completely forgot about the info.json file. Bumping to 1.5.63 to remedy it.
-
@DV-JF Thanks for reporting. 1.5.62 released with fixes. Please test and let me know if all's good.
-
Version 2 of this module has been published. It now has support for Composer (via composer-installers). PW >= 3.0 and PHP >= 7.4 is now required. Dependencies updated. Please let me know if you bump into any issues.
-
Thanks @gornycreative I'll see if I can get a new version published this weekend.
-
Hi all, I've released 0.9.0, which brings the minimum PHP version to 7.4, adds support for PHP 8, and adds support for Composer 2. Also released 0.9.1 which handles @gebeer's suggestion (thanks!). Note, however, that I've published these versions on a hunch that they will be ok – I do not have a PW setup for testing. If something is broken, let me know and I'll fix it.
-
Hi guys, I'm afraid I don't have the time to maintain this module, and would prefer if someone took it over, along with Jumplinks. The simple reality is that I don't do website development anymore and, by extension, don't use PW anymore, and so I feel it best that these modules be handed over to someone who is active with PW and would be happy to take them over. If you'd like to do so, please drop me a DM and we can take it from there.
-
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 ?
-
@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?
-
@adrian Thanks, I'm surprised I didn't cover this (thinking back, I thought I did). Will take a look-see as soon as I can. The idea is that it should support it - because it is valid. @wbmnfktr Noted, I've replied to your DM.
-
Thanks for reporting – 0.8.2 has been tagged with the fix.
-
Hi guys, sorry about this – will push a fix up shortly.
-
@Peter Knight - That's odd, I was quite sure this bug was fixed. Internally, the module stores a schema version and then it does a comparison to see if an update is required. So if it is adding this column again, it means the stored schema version went out of sync. Could you check the database to see what the _schemaVersion is set to? Not sure which table it is, but it should be relatively simple to find.
-
@Peter Knight Hi Peter – the module won't clear out 404 history automatically, I'm afraid. You'll need to continue doing this manually every now and then.
-
@PWaddict 0.8.0 has been released with the selected change. Please let me know if you encounter any issues.
-
@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…
-
1.1.0 released with support for formatting text outside of the field context. You can now use the following to format arbitrary text: print $modules->get('TextformatterTypographer')->formatString($text); Note that this new method does not use by-reference passing of the input text.
-
@ErikMH – Hi Erik, The module wasn't intended to be used manually like that. Normally, you would apply the module as a formatter for the field in question by modifying the field's configuration. Under the hood, the formatValue method is called, which imports the vendor packages and runs the formatter. I guess if you wanted to, you could call this method manually, but you would need to pass in an instance of the current page and field. Here is the method signature that it uses: public function formatValue(Page $page, Field $field, &$value); The value is passed in by reference. I guess I can see that there might be use-cases for calling the method outside of the PW field system, so I reckon I should add a method to format arbitrary strings without the page and field dependencies (which are not used anyway - it's just the method signature that PW uses for formatters).
-
Hey @Peter Knight All redirects are 301s, unless they are timed.
-
I figured it might be a bit of work to add additional git services so I've mirrored the repo over to GitHub and released v1.
-
Ok that seems to have been due to caching - the module system heavily caches frontend pages, which it shouldn't really be doing for pages that require authentication... Anyways, I have a new problem now. It seems that PW no longer accepts projects that live outside GitHub (it used to, as the current module points to the GitLab repo). @ryan – would it be possible to allow non-GitHub repositories?
-
Hmm, I'm trying to release v1 but the module system won't allow me to. I'm signed in, and the module is listed, but clicking on edit takes me back to my module list... Can somebody help me out with this?
