Leaderboard

Format Datetime fields as Carbon instances. You can find the latest release and the complete readme on Github. Installation composer require daun/datetime-carbon-format Usage All Datetime fields will now be formatted as Carbon instances instead of strings. Some examples: // $page->date is a Datetime field // Output format: j/n/Y echo $page->date; // 20/10/2020 echo $page->date->add('7 days'); // 27/10/2020 echo $page->date->format('l, F j'); // Monday, October 20 echo $page->date->year; // 2020 echo $page->date->diffForHumans(); // 28 minutes ago Frontend only The ProcessWire admin seems to expect datetime fields to be strings. This module will only return Carbon instances on frontend page views. Date output format When casting a Carbon instance to a string (usually when outputting the field in a template), the field's date output format will be respected. Links GitHub • Readme • Carbon docs PS. I remember reading about a Carbon module in a recent newsletter, but couldn't find it anywhere. Was that you, @bernhard?

"exe" is among the file extensions that is blocked in WireUpload.php /** * Disallowed extensions for uploaded filenames * * @var array * */ protected $badExtensions = array('php', 'php3', 'phtml', 'exe', 'cfm', 'shtml', 'asp', 'pl', 'cgi', 'sh'); But it turns out you can override this by setting your own custom array of blocked extensions in your /site/config.php // Remove "exe" from array of file extensions blocked by WireUpload $config->uploadBadExtensions = array('php', 'php3', 'phtml', 'cfm', 'shtml', 'asp', 'pl', 'cgi', 'sh'); Of course exe is probably blocked by default for a reason so you would want to do your own research about possible risks involved in allowing such files on your server.

Hello @Robin S - and thanks for your efforts! I've optimized the auto init a bit so that it kicks in earlier and now it is in the line with 1.1 version. Or actually it is slightly faster and FOUC is almost unvisible. I also implemented the other two suggestions that you had: Wrapped replace text to noscript tag instead of span that prevents FOUC completely. Also added version number to JS autoload filename as a query string. While I was there I replaced skipped form tag with individual form elements and also added couple of attributes to the mix. Now obfuscation is skipped in following: Tags: head, script, textarea, option, output, input Attributes: value, label, data Version 1.2.4 is available at Github: https://github.com/BlowbackDesign/EmailObfuscation/releases/tag/1.2.4

Man, it´s always easier as it looks like... Thanks a lot - I have to see it from the page´s angle. Thanks a lot! It works now... If I´m ready I will show you my work.

Definitely not! That's not how we roll in this community. I guess you should start here then? https://processwire.com/docs/start/templates/ It's always the name of the field :-) <?php namespace ProcessWire; // will yield its value // @note: the value can be as simple as a string or integer, or more complex, e.g. an array or object // @note: that field must be present in the template that this page uses $page->name_of_field; In other words the 'name of the field' is a property (some would say attribute) of that page. Just like things (humans, buildings, animals, etc) have properties/attributes: height, width, etc. Edit Also note that $page always refers to the current page, but the principle of 'name_of_field' still applies. For example: <?php namespace ProcessWire; // this page we are viewing // get a property from it. $height = $page->height;// height is the name of an integer field in the template used by this page echo $height; // get another page not currently in view // get it using its ID $anotherPage = $pages->get(1234); // this other page uses the same template as our 'current page' above // so, we can get its height property as well $anotherPageHeight = $anotherPage->height; echo $anotherPageHeight; // @note: we only echo 'simple' field values, i.e. those that do not return an array or an object, etc

Welcome to the forums and to ProcessWire @brandy :-). I don't know how much of the docs and/or tutorials you have gone through already. If you haven't already seen the docs about $page and $pages. I'll also throw in selectors. You'll get along better and farther with these under your belt.

I will keep that in mind. Thank you Robin ?

@tpr, could you please make the styles that AOS applies to Select2 more targeted so that it's possible to use Select2 separately in the PW admin without being affected by AOS styles? At the moment there are AOS styles like this... .select2-selection.select2-selection--single, .select2.select2-container, span.select2-dropdown { width: auto !important; min-width: 300px !important; max-width: 640px; } ...which will apply to every Select2 instance and are impossible to override to get back the inline style that Select2 uses to set the dropdown width dynamically. It would be better if these could be something like: .aos-select2.select2-selection.select2-selection--single, .aos-select2.select2.select2-container, span.select2-dropdown { width: auto !important; min-width: 300px !important; max-width: 640px; } See "dropdownCssClass" and "selectionCssClass" in the Select2 options. Thanks!

What we're discussing is a feature request rather than a bug to report, and there already is the feature request I linked to in my earlier post. I've added a comment linking to this thread but like all such things Ryan will just get to it when he gets to it. This is feature request 13 of 269 and counting. ?

Hi, After this did not help, I noticed that the 404 page was missing. It seems that my client simply renamed it and filled it with content. ? That was obviously the problem. sorry and thanks for your quick help!

Thanks kongondo It is indeed as simple. Both version work actually. $p = $pages->get(1234); $p->of(false); $p->page_reference_field->add(1111); // add another page by id $p->save();