TheMick

Just for future readers looking for an easy solution:

If you install the PagePathHistory Module you can add additional paths for a page in the settings of the page.

Does this module work with Repeater / Repeater Matrix in the current version? After the posts of adrian and zoeck in 2018 I did not read anything about this.

And thanks for this awesome module @teppo!

On 6/16/2020 at 10:11 PM, Violet said:

? My question is, I'm wondering if there is (or could one day be) a function in the ProcessWire API that as a one line command, converts images on a page to a (temporary) page array, each element of which contains one image? ?The idea being that the resultant page array could be used directly for pagination purposes just like any other page array, which is handy for image gallery situations such as this. It seems like it's a common issue people are facing.

@Violet I wonder if you missed the well explained solution of gingebaker here in this thread:

Isn't the PaginatedArray class just what you are looking for?

@ryan Does ist still make sense to have such a restrictive function for filenames?  

I prefer to load jquery-migrate for editors after jquery:

if ($page->editable()) { echo '<script src="/path-to-js/jquery-migrate-3.3.2.min.js?NoMinify" defer></script>'; }

This way you have at least the full functionality of the current jquery version for the editors, too.

The same problem is dicussed here.

Not really a solution, but you can instead load jquery-migrate for editors after jquery:

if ($page->editable()) { echo '<script src="/path-to-js/jquery-migrate-3.3.2.min.js?NoMinify" defer></script>'; }

This way you have at least the full functionality of the current jquery version for the editors, too.

The same problem is discussed here.

For those who are searching - there is a hook now:
https://github.com/processwire/processwire-requests/issues/226

For those who are searching: The mentioned request was completed (https://github.com/processwire/processwire-requests/issues/226) and there is a hook now.

Google allows to restrict API keys, but you can only restrict to URLs (useful for showing maps) or IP-addresses (useful for geocoding with PHP). I tested the inputfield using API keys with one of the restrictions each and one with no restrictions. The (expected) result:

• key restricted only to URL: Map in the inputfield works, geocoding with hitting enter (not clicking outside the field before) works
• key restricted to IP: Map does not work, but server-side geocoding (with PHP on save) works
• key with no restrictions (not recommended!): everything works

So I think, there should be two fields for the configuration in the module: one for a server-side key and one for a frontend key (also used fro the inputfiled map). Or do I get something wrong?

Something else I noticed: In InputfieldMapMarker.module on line 79 and in MarkupGoogleMap.module on line 161 I think the domain should be googleapis.com instead of google.com

Thanks for the info! Really searched quite a bit but did not find it. Having a look in corresponding the weekly update seems to be a good idea ?

I get this error after an update from a two weeks old 3.0.165 install to 3.0.172 for the LazyCron module:
Configurable module check failed for LazyCron. 

Many (!!) times of Modules > Refresh did not change anything. Same with deinstalling and installing again.

Any ideas what could be the reason or how to get rid of this error? Is there anything to worry about?