Leaderboard

Anything that repeats in any programming language calls for, invariably, something you can iterate/traverse (e.g. an array) and the tool you use for the traversal/looping, (e.g. foreach). Let's go with these two. Looking at the UIkit markup you've pasted, I suppose some of the classes are automatically injected by UIkit JavaScript. However, the basic structure of the markup that repeats is the same. Hence, I'll ignore markup classes for now. The main differences in the images ratio markup are the following: The main containers for the images vary in the class they have. The first, the second and the fourth have the class: <div class="uk-width-expand@s">...</div> The 3rd image container has a different class: <div class="uk-width-2-3@s">...</div> Secondly, the <img> markup themselves have different values for their data-height attribute. Hence, we will need some variable to store these differences. Although some of the values are shared, for instance, the class for the main images container for the 1st, 2nd and 4th images (as stated above), I prefer to store each image's values separately. This can help down the line if the markup changes resulting in different values that were previously identical. Although it may be simple to assume that the images in your image field (which I will refer to as images) are already arranged in order and are in the correct size, from experience, we know that this will most likely NOT be the case. Clients can upload images that are not of the correct size and arrange them randomly. You may need to cater for this, e.g. have the clients tag the images with first, second, etc....but that may be too much work. OK, for the fun part. Please note that in the examples below, I only focus on the images' container part. I have also left in the CSS just for reference, although they may be auto-injected as stated above. We have at least two ways to loop through our images. Both ways involve having an array that will have 4 nested arrays, one each for our 4 images. The first way to loop through our images is to loop through the images themselves and access the array with images info inside this loop as shown below: The main downside to the above approach is we are assuming there will always be four images in the images field. What if a client adds more? What if there are less images? All these will require adding checks in the code (within the loop) to check how many images we have. To counter some of these challenges, we can instead loop through the array with the info for images as shown below: This is just basic code to get you started. There are a number of things that could be improved. For instance, you may want ProcessWire to resize the images for you (done once) rather than depending on your browser to contain larger images. See the Resize and crop section in the API documentation here. There are alternative approaches as well to the examples shown above. PS: code untested

This looks amazing, thanks for your effort and your transparency in developing this module. Please make it very obvious how to donate or contribute to the project in whatever way is helpful ?

You might want to also validate the date when the page is saved as @BitPoet suggests, but it is possible to limit the datepicker to only future dates with some custom admin JS. The relevant option is minDate. The core sets the datepicker options on focus, so to ensure the custom option doesn't get overwritten I've found that the most reliable way to apply it is by using a beforeShow function. For a Datetime field named "crondate": $(function() { $('#Inputfield_crondate').on('focus', function() { $(this).datepicker('option', 'beforeShow', function() { return { minDate: 0 }; }); }); }); Edit: just noticed you want a minimum time also. Try this: $(function() { $('#Inputfield_crondate').on('focus', function() { $(this).datepicker('option', 'beforeShow', function() { return { minDate: 0, minDateTime: new Date(new Date().getTime() + 30 * 60000) }; }); }); });

Why is the corresponding table not automatically deleted by ProcessWire after a field is deleted in the admin panel? Now I have numerous "dead" tables of no longer existing fields in the database of my ProcessWire installation. Or is there a configuration that I have missed? Thanks for your support.

Hey Robin, great stuff! Works as a great addition to the server side validation by BitPoet! Thank you very much! ?

just updated to v1.1.4 with the bug fix

@ngrmm thanks for letting me know about that config issue. Will get that sorted in a min. On the SendGrid front I'm not too sure. SendGrid should show sent and received stats for all messages, therefore if you're not even seeing that (and the message is delivered) then something else is probably not quite right.

Hi @e0f, Currently, this is not doable out of the box. However, using the method getMenuItems() (see a few posts up for examples), you can use the property pagesID (or index pages_id if getting back array of menu items) to get ($pages->get($m->pageID), for example) the respective ProcessWire pages of the menu items and return the custom fields you want, e.g. description. Having said that, I would not recommend this. It seems like an overkill and may not be very performant based on the number of menu items and other factors. Perhaps if you could explain your use case, I would see if I can add an option to retrieve the values of simple fields (text, integers, dates, etc) for use with getMenuItems(). MenuBuilder is primarily for building navigation menus. From your example, it seems you are using it for a different purpose? Maybe provide a fuller example so that I can get my head around this.

Done!

Done! ? - donation button in GitHub repo, forum signature and initial SnipWire forum post. (I hope this is not against forum rules?)

The session cookie is unique to a browser session, and seldom used without you holding more information about the user, which by my impression does fall in the definition of personal data how gdpr defines it: https://gdpr-info.eu/art-4-gdpr/ But as I said the gdpr doesn‘t explicitly demand banners. It demands that users are informed about the usage of the data (privacy documents).

It does, it's just not documented unfortunately. I linked to information about it in my earlier post above. Here is a demo... Page structure: Field settings for subcategory field: "page.category" will be replaced with the ID of the page selected in the Category inputfield in Page Edit, whenever that field changes. The "has_parent" part is just to avoid unwanted pages appearing in the Subcategory inputfield if the Category inputfield is changed to empty (no page selected). Result:

Did you check the database to see if the table is in fact still there?

The GDPR doesn't actually handle cookies specifically. GDPR is about processing personal data. A cookie is processed by a webserver when a user accesses your website, so GDPR is applicable IF there is personal data involved in regards to the cookie. Even a simple session cookie is personal data, because it identifies a certain browser session, which in turn likely identifies a person. There are a few things GDPR demands you to provide to users in such a case, like what the data is used for (Art. 13/14) and it needs to have a legitimate reason (Art. 6) for you to be allowed to do so. This is even more complex if it's not a cookie set by your website, but by a third party. There it's the shared responsibility between your and the third party that everything is handled correctly. This is usually done with DPA (data processing agreement) which is a binding contract where both parties essentially guarantee each other GDPR compliance. The GDPR gives users the right to deny consent wherever you cannot use Art. 6 1.f) as legitimate reason. Therefore cookie-banners with the option to not have certain cookies set. The GDPR also says you may not auto opt people into giving consent, therefore the default for optional cookies should be unset. Besides the GDPR there's afaik a law in Germany for cookies specifically, which has been the kinda predecessor for the long overdue EU wide ePrivacy directive. I'm not as well versed with this one. It was essentially the law, which started all the cookie banner stuff.