Leaderboard

Last Saturday we started getting hit with heavy traffic at the processwire.com support forums, and it soon became a full blown DDOS frenzy. This post describes all the fun, how we got it back under control, and what we learned along the way— https://processwire.com/blog/posts/driving-around-a-ddos-attack/

The $page->links() method takes two optional arguments: NAME TYPE(S) DESCRIPTION selector (optional) string, bool Optional selector to filter by or boolean true for “include=all”. (default='') field (optional) string, Field Optionally limit results to specified field. (default=all applicable Textarea fields) You are passing only one argument, so this is interpreted as the first argument. Passing "$field='blog_body'" doesn't make this become the second argument - your code is saying "pass the string 'blog_body' as the first argument and also assign the string 'blog_body' to a variable named $field". If you want to specify the second argument (field) but not the first (selector) you need to pass a value for the first argument, and in this case you would pass the default value which is an empty string. So you would do this: $items = $page->links('', 'blog_body'); It would be reasonable to think that you could pass a sort as part of the selector argument, but actually this doesn't work because behind the scenes this method is ultimately just getting some page IDs and then loading data from the database using those IDs without any ORDER_BY clause. So you'll need to sort the links after you get them: $items = $page->links('', 'blog_body'); $items->sort('-blog_date');

Ryan 1, China 0. This was a fun read.

Thanks, try the latest version.

try has() $segment = $sanitizer->int($input->urlSegment1); if($allguests->has($pages->get($segment))) { echo "yep"; }

The way that I find easiest is to get the Field object that is associated with the Inputfield via hasField and check its name, because the Inputfield object's name changes inside a Repeater but the Field object's name doesn't. So something like this: $wire->addHookAfter('InputfieldDatetime::processInput', function(HookEvent $event) { $inputfield = $event->object; $field = $inputfield->hasField; if(!$field || $field->name !== 'your_field_name') return; // ... });

Yes. Some possible solutions, in order from easiest to hardest or least recommended: 1. Use FieldsetGroup instead of FieldsetPage if you have ProFields. 2. Use a normal Fieldset instead of FieldsetPage, and just bite the bullet if you have to spend some time setting up the fields in multiple templates. 3. Write some custom JS for the admin that adds/removes the HTML required attribute to the adjacent field depending on the state of the checkbox. 4. Use a hook to a processInput method to do custom validation for the required fields. So if your required field is a text field then you would hook InputfieldText::processInput. Here is an example for a text field named "text_1" that is required if a field named "checkbox_1" is checked inside the same Repeater item (or FieldsetPage item): $wire->addHookBefore('InputfieldText::processInput', function(HookEvent $event) { /* @var InputfieldText $inputfield */ $inputfield = $event->object; // Get field $field = $inputfield->hasField; // Only for field "text_1" if(!$field || $field->name !== 'text_1') return; // Get page $page = $inputfield->hasPage; // Only for fields in a Repeater page if(!$page instanceof RepeaterPage) return; // Repeater suffix $r_suffix = '_repeater' . $page->id; // Get checkbox field $wrapper = $inputfield->parent; $checkbox = $wrapper->getChildByName('checkbox_1' . $r_suffix); if(!$checkbox) return; // If checkbox is checked then field is required if($checkbox->value) { $inputfield->required = 1; } else { $inputfield->required = 0; } }); If you have multiple required fields you'll need to adjust this to suit. 5. I posted some suggested changes to the core to support required-if inside Repeaters here: https://github.com/processwire/processwire-requests/issues/262 But making custom changes to the core is not recommended because they will be lost when you upgrade.

@ragnarokkr, i've read a little of this thread and am wondering if you're aware you can set a page to be a system page and then it is not going to be deleted. I don't see the difference between using a page in the tree for storing images (or a page with children) vs. a folder. Either one can be deleted. But setting a page as System, Non-deletable and locked ID, name, template, parent (status not removeable via API) is probably even more solid than a folder.

Definitely an interesting topic! We've developed a few PWA's for our clients recently, and I'd say that they've been very well received — but, to be fair, they've been a) services for existing members and b) basically apps that wouldn't work (well) as regular websites, so that option was out of the question. When it comes to native vs. PWA, in our case PWA seems like the obvious choice: easy to use and efficient to maintain, upgrades are effortless, and obviously the web platform is "our thing" (more than native anyway) ? Some "random" websites (news sites, blogs, etc.) are now offering the option to install, but to me that feels a bit weird: unless it's a service I'm going to use regularly and there's a clear benefit for me in installing it, I don't really see the point. In fact it can also be a little intimidating: why do I need to install this service to use it? Again I think it boils down to the question of "would it work as a regular website": if the answer is "yes", then perhaps it should just be that ?‍♂️ (Sorry to hijack the thread, by the way!)

Opened an issue for this here: https://github.com/processwire/processwire-issues/issues/1083. It's great that http to https redirects are finally in place (assuming that this was intentional), but it appears that it's going to be an issue for the core.

@dragan Yeah, that's my experience as well. We're not using Google Analytics or Tag Manager anymore because of privacy concerns. To comply with the GDPR, we're now mostly using our own Matomo instance. The tracker is configured to not set any cookies, IP adresses are masked et c to yield completely anonymous statics. You can read about our approach here (in German). Anyway, we have some event tracking set up to track the installs. On Android, we can track both the native dialog as well as the user choice using the beforeinstallprompt event and the userChoice promise. On iOS, there's no PWA install event, so we can only track the popup that informs the visitors about the PWA installation. I've also set a campaign parameter that should be tracked when the PWA is started from the home screen (https://architekturfuehrer.koeln/manifest.webmanifest), but the amount of campaign reports are almost zero, so either some devices aren't correctly including the parameter, or opening rates are even lower than installations ?

I believe the directory itself is the issue, it is "broken" at the moment. Broken because it forwards HTTP to HTTPS and this causes the check to fail, because the non-HTTPS url is hardcoded in the config file. Edit: So this is happening on all sites since yesterday. I tracked down the issue to the non-SSL service URL in the wire/config.php file. You can fix it by changing the $config->moduelServiceURL in your site/config.php like this: $config->moduleServiceURL = 'https://modules.processwire.com/export-json/';

Sad to hear that. But can understand your frustration. People coming from WP are used to have new functionality installed with one click. PW just uses a different approach here. And there are custom modules like Media Manager or ImageReference that can do what you need. That is exactly what ImageReference aims to do. I am sorry that it doesn't cater for all of your needs (yet), like descriptions for images from folders. That would be what I meant with hiding the image page in the page tree. The link I provided contains code for such hooks. If you don't know how to put a hook together for your exact use case then describe the problem and I am sure someone will help you out here in the forums.

I wanted to write a bit of an update since this project was so well received last year. The Architekturführer has now been online for about nine months, and we have been getting mostly positive feedback. Thankfully, I was able to resolve all issues with Google's indexing of the page. The site's SEO is actually pretty solid now, being one of the first results when searching for "Architekturführer" (at least from within Cologne). We have also added some new content and restructured some pages. The homepage, for example, now features only selected projects. An iconic new entry that everyone who's been to Cologne in recent years will recognize is the Rheinboulevard Deutz. There's also an entirely new section for architecture-themed walks (Spaziergänge) that you can take in different areas of the city. If you come to visit for a day, make sure to check those out ? Finally, we got some traffic through word of mouth and a couple of architecture news sites, the visitor numbers are steadily rising each month. The only thing I find a bit lacking is that the number of PWA installations are very low. It seems the whole PWA concept has not really come through yet, or maybe it's just not that much of an added benefit compard to the normal site. I'm interested to see how PWAs will fare against native apps in the future, once they become more widely adopted.

With Image Reference you can have all images on one page (that can be hidden in the tree). Then you set the ImageReference input field to pull images only from that page. Please note that I already have pushed a fix 2 days ago for the responsive issue you posted on GH. The scrolling you are talking about is really only needed for rare edge cases like yours where the ImageRefenrence input field in the page edit screen is very narrow. Please understand that I will not cater for that edge case. You might want to rethink the layout of your gallery input in the page edit screen. If you need descriptions for your images, you can reference them from a hidden page (like mentioned above) instead of from a folder. If someone tries to remove an image from that page and that image is still being referenced somewhere else, the module will give a warning and will not allow to remove the image before all references to it were deleted. So this option could be a solution to your use case.