Leaderboard

If you don't create any variations on the front-end using size, width, etc. calls, ProcessWire won't create anything except for the variations created by default for admin (preview) purposes. Third party modules may still create their own variations, but if you're strictly against that behaviour, you can always avoid using any modules that do this ? What you're probably missing here is the amount of data: sure, browsers can handle resizing images, but if you're considering load times and amount of data users have to download to use your site, you absolutely want to resize images before they hit the visitors' browsers. When you're asking if this behaviour should be disabled to "reduce additional http requests (if the user resizes viewport)", it kind of sounds like you've implemented srcset on your site – otherwise there shouldn't be a additional requests when the viewport is resized due to images. Even then if you start with a larger viewport and then resize it to smaller size, browser shouldn't load the smaller sizes. Only case generating additional requests is when you go the other way, from small to large – otherwise tiny images would likely look pretty awful scaled to a larger size. Short answer is: no, it shouldn't be disabled. That being said, you don't have to create any additional variations if you don't want to – but be considerate of the user and don't make them download more data than they actually need ?

Relative to the last dev branch version (3.0.127) version 3.0.128 contains 40 commits, mostly specific to resolving older GitHub issue reports. If you are interested, here is the commit log: https://github.com/processwire/processwire/commits/dev — version 3.0.128 covers commits between March 2nd and today. We're down to about 77 remaining issue reports, mostly older stuff that didn't get covered in the past for one reason or another, but we're making good progress. Similar updates will be continuing next week, and I've also got several ProMailer updates coming out next week too. Hope you all have a great weekend!

Why don't you modify or create your own CSS for it?

Access By Query String Grant/deny access to pages according to query string. Allows visitors to view protected pages by accessing the page via a special URL containing an "access" GET variable. This allows you to provide a link to selected individuals while keeping the page(s) non-viewable to the public and search engines. The recipients of the link do not need to log in so it's very convenient for them. The view protection does not provide a high level of security so should only be used for non-critical scenarios. The purpose of the module was to prevent new websites being publicly accessible before they are officially launched, hence the default message in the module config. But it could be used for selected pages on existing websites also. Once a visitor has successfully accessed a protected page via the GET variable then they can view any other page protected by the same access rule without needing the GET variable for that browsing session. Superusers are not affected by the module. Usage Install the Access By Query String module. Define access rules in the format [GET variable]??[selector], one per line. As an example the rule... rumpelstiltskin??template=skills, title~=gold ...means that any pages using the "skills" template with the word "gold" in the title will not be viewable unless it is accessed with ?access=rumpelstiltskin in the URL. So you could provide a view link like https://domain.com/skills/spin-straw-into-gold/?access=rumpelstiltskin to selected individuals. Or you could limit view access to the whole frontend with a rule like... 4fU4ns7ZWXar??template!=admin You can choose what happens when a protected page is visited without the required GET variable: Replace the rendered markup Throw a 404 exception If replacing the rendered markup you can define a meta title and message to be shown. Or if you want to use more advanced markup you can hook AccessByQueryString::replacementMarkup(). $wire->addHookAfter('AccessByQueryString::replacementMarkup', function(HookEvent $event) { // Some info in hook arguments if needed... // The page that the visitor is trying to access $page = $event->arguments(0); // An array of access keys that apply to the page $access_keys = $event->arguments(1); // The title $title = $event->arguments(2); // The message $message = $event->arguments(3); // Return some markup $event->return = 'Your markup'; }); Screenshot https://github.com/Toutouwai/AccessByQueryString https://modules.processwire.com/modules/access-by-query-string/

I don't want to undermine your suggestion but in my opinion the presets are fine. There is no one-size-fits-all-needs solution in this case. All websites are different in the matter of design and how it was achieved. I think the provided solutions are a very nice foundation that almost work in most situations already. At least they are a good starting point to build custom solutions later on.

I don't have much to add to previous feedback posted already here, except that delivering a suitable (physical) image variation is good practise. It impacts page speed performance and also affects mobile SEO ranking: https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html Even in 2019, not everyone has ultra high-speed internet access everywhere and all the time.

Thank you! I might give it a try. It would be really helpful, the way I believe repeaters are meant to be used, if we could sort them by fields, or set new items to be placed on top of the list... Basically a more flexible element. And by the way - I'm so happy about processwire and the way it works ?

Indeed, at the moment there is no version available for testing, but this will change pretty soon. Since the RepeaterFlex is pretty similar to the RepeaterMatrix regarding its use (yet totally different regarding configuration), I've requested @ryan for an approval first on how to proceed. As a result the RepeaterFlex will be made available from the ProFields board after some final cleanup and documentation. ...hopefully next few days.

@Robin S has already provided us with hundrends of goodies, one of them this deals with it: https://github.com/processwire/processwire-issues/issues/70#issuecomment-258023285 same in the forum: https://processwire.com/talk/topic/1674-sorting-repeater/?do=findComment&comment=131713

The following seems to work: In $defaults (below line 46) add 'template' => '', Below line 265 (now 266) add $template = !empty($settings['template']) ? $this->templates->get($settings['template']) : null; $template_id = $template ? '&template_id=' . $template->id : ''; Amend line 267 (now 270) to $editUrl = $this->wire('config')->urls->admin . 'page/add/?parent_id=' . $parent . $lang . $fields . $template_id;