LostKobrakai

$event is the HookEvent object, that's passed into each hooked function. It holds all the information needed about the hooked function, arguments, objects, return values and so on.

$sanitizer->url($value, array( "allowQuerystring" => false ));

If you disable the "allowQuerystring" option the issue should be gone. The setting tries to fake a domain for relative urls with query string and somehow "http://processwire.com/http://" is a valid url for php. But http:// is definetly not a valid relative url, so it would be nice if you could open an github issue about this. You can just link to this topic.

Yep. Everything startup related is basically in this order: index.php -> /wire/core/ProcessWire.php ^ index.php -> /wire/modules/Process/ProcessPageView.module

I'm not much of a help here, but I had to smirk when reading "smooth jquery animation" in the description. If it should be smooth one shouldn't use jquery.

The sanitizer is internally relying on php's filter_var() function, which for me does return false for the string "http://".

There's the page_parents table in the db, which holds all the hierarchy related information. And the actual db query is just more or less a simple $pages->get("path=/mens/tshirts/…/");, which you can find in ProcessPageView::getPage(). If the first try won't find anything it just checks each hierarchy above if pages are found and if so, the other parts of the url are further evalulated as urlSegements. The actual domain is only checked against the $config->httpHosts whitelist and not really involved in the page finding process.

Even repeaters and page-tables just create real pages, so there shouldn't be the need to differentiate between those. I've not much time to look into your code, but I wouldn't search those images by pages, but rather check the list of fields ($fields api variable) for all image fields you have in your installation. Those fields can give you all templates they are used on and with those templates you can find all pages, with an image field on. Just keep things like pagination and timeouts in mind here, as the number of pages you can load on one request is limited. One improvement to this issue could be not loading the whole pages data, but using direct sql queries to just select the image-fields rows and working with them if you don't need other related data from those pages.

You could always use another type of cache, instead of ProCache.

When will this be executed? ProCache skips any php occurrence in the request by directly going from .htaccess to the cached files.

If you can create a .htaccess rule, that can detect your users rights / levels, than you can use ProCache. Otherwise you'd need to look for an alternative caching solution.

This seems to be fixed on the dev version, as the line does hold other code. Could you confirm that? Otherwise it would be nice if you would report that on github, so Ryan can fix any remaining issues: https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/modules/Fieldtype/FieldtypeComments/comments.js#L78

You mean those 16x16 blobs of random pixels? It's indeed shitty, that they require own files for each damn iconsize they use, but not using favicons I can understand.

Actually that's how this should be. Never change a running system, especially if you've no clue about the details of the system. Only exception are critical security updates.

Maybe not the most efficient, but I'd hook into Pages::added, if the template is the repeater template and all fields are empty just delete the page itself.

The error essentially means something is trying to insert a record in the database with the unique key being one, that's already present. Not very helpful on it's own, but the db doesn't have any more knowledge about what you're trying to do at that point.

I think diogo fell in the copy/paste trap here. You need to check the count of the field instance of the page. $page->fields->… will get you the field's properties, but not actual data. if($page->adr_rubrik->count()){ // just syntax sugar for: count($page->adr_rubrik) … }

Some enhancements could be: - A setting to chose thumbnail size, maybe even giving the users the option to choose by themselves. - Moving the images folder out of the module's folder. It should rather be part of the assets or templates folder.

Do you have any examples of such edge cases?

Then take a look at $config->sessionExpireSeconds.

A given time of inactiveness or from the login? Also does this need to be different depending on the user?

Not quite Q2 of 2015, but the certs are finally trusted by major browsers and therefore really usable (even if I'd try it on private projects first): https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted.html

On mobile, therefore only the link: https://processwire.com/talk/topic/9730-get-pages-used-by-a-pagefield/#entry97705

That's the right way to do things in that case