Leaderboard

Hey @ryan this sounds great ? Could you please have a look at https://github.com/BernhardBaumrock/RockDatetime and see if that might be something that find its way into the core? I think some solid date and time handling API would be a great addition to PW! RockDatetime was developed because I need it for a new module that I'm working on for dealing with date ranges. See this recent post from today about the latest additions: I'm especially talking about this post: https://processwire.com/talk/topic/23097-previewdiscussion-rockdaterange-fieldtype-inputfield-to-easily-pick-daterange-or-timerange/?do=findComment&comment=198191 It's neither well tested nore complete. But feel free to copy/paste/improve as much as you want ? I think having an API for dates and times would be a very logical addition to the PW API awesomeness ? I'm talking about things like this: // calculating FROM/TO for RockDaterange case 'hour': $from = new RockDatetime("{$obj->date} {$obj->time}:00:00"); if($isTo) $to = $from; else $to = $from->copy()->move("+1 hour"); break; // check if FROM starts at 00:00 on that day if($this->from->equals($this->from->firstOfDay()) ... // show modified date when different from created day $updated = new RockDatetime($page->getUnformatted("modified")); $date = "Zuletzt aktualisiert am ".$updated->format("%d.%m.%Y"); if($updated->sameDay($page->getUnformatted("created"))) $date = ""; // formatting $d = new RockDatetime("25.02.2020 14:00"); echo $d->format(); // 25.02.2020 14:00 echo $d->format("%A, %d.%m.%y (%H:%M Uhr)"); // Dienstag, 25.02.20 (14:00 Uhr) echo $d->format(['time' => "%H|%M|%S"]); // 25.02.2020 14|30|00 On a side note I want to ask you if you please could consider to have a look at this request: https://github.com/processwire/processwire-requests/issues/326 I'm struggling on almost all my module development with proper file path and url handling and I'm doing the implementations over and over again because I don't want to add a module dependency for that. This little thing should really be in the core! We've had some problems with windows/unix file path handling recently and it shows again how important it is to have the right tools at our hands without implementing those things on our own: PS: As I've started to build my first "real" Fieldtype module with custom DB schema I want to say thank you for that awesome piece of software that you've developed here! Unfortunately there are no docs about that and the Events Fieldtype was at least for me not of much help, because it's hard to know where to start and what to add where and at what point of time to make everything work together. But once you get how it works it is really brilliant! I hope I can write a blog post about that some day if there's interest in that. So far I'd just want to express my appreciation ?

I’ve been working on some major upgrades to our InputfieldDatetime core module and they are just about ready, but because there’s a lot of new code involved, I just want to test things out more thoroughly before pushing to the dev branch. I’ll have more details on this for you next week, but here’s a summary of what’s new in our Date/Time Inputfield coming in 3.0.152: If you’ve used date inputs in ProcessWire before (whether in the admin, FormBuilder or elsewhere), you know that they consist of a text field with a configurable date format and optional jQuery UI powered date picker. On recent projects, I’ve wanted more options here. First off, I’ve wanted support for the HTML5 “date” and “time” input types, because on some browsers (mobile-based in particular) the browser implementation is quite good. On mobile clients (testing in Android Chrome at least), I find it’s actually pretty amazing, certainly preferable to the jQuery UI date picker. On desktop clients, I think the jQuery UI date picker might still be preferable, but the browser implementation is still quite good (though varies widely from browser to browser). So I’ve upgraded InputfieldDatetime to support both HTML5 “date” and “time” inputs as configurable options, as well as the ability to use them both together. Another thing I’ve often wished for when it comes to date inputs is the ability to have the Month, Day and Year isolated into separate selects. This is something that would work in any environment, and not require any particular feature support from the browser, nor would it require jQuery UI (like if you are wanting lightweight date fields in FormBuilder). This type of date selection seems to be the simplest, easiest and most portable way to go, and it’s something I’ve wanted for quite a long time. So support for this has also been added to InputfieldDatetime this week as well! Of course the order of month, day and year is completely configurable. Some other useful additions include support for HTML5 step values (date or time), minimum and maximum dates (and times), support for seconds in time selections, automatic localized month names in selects (via strftime), and the ability to ask for just month and year (when day is not applicable), or month and day (when year is not applicable). These updates—along with others—will appear in ProcessWire 3.0.152 on the dev branch within the next week.

Another perspective: The API acts as the model, with the $page / Page class giving you access to page data through a generic interface. By default, the PHP template file for the current content type / template acts as Controller and View, though you can easily seperate Controller and View by using, for example, a frontend templating library like twig. That's close to my usual setup: View: Twig acts as a View layer, since it gets pretty privileged access to API variables, you can get anything done you'd usually do in a PHP View class. Controller: The PHP template file acts as the Controller, for example processing input and rendering the correct Twig template. Usually, I just keep the template logic procedural, because ProcessWire already does a lot of work in determining the correct template file and setting up API variables. Though you could also use a custom Controller class and just use the template file to instantiate it. Model: As mentioned above, the $page API variable is already a kind of generic model for your data, and for sites that are mostly brochure sites / presentational in nature, this is really all you need. But if you want to go further, you can create custom page classes by extending the Page class and set your template to use that, this way you can make your model as smart as it need to be. I have written two tutorials on how to integrate Twig if you're interested ? Part 1: Extendible template structures Part 2: Custom functionality and integrations

Hello, Recommend @teppo's module:

Just to clarify this a bit: 1. No (out of the box). 3. ProcessWire doesn't enforce any specific architecture on you; instead you can utilise just about any architecture/strategy you want. If you haven't yet had the chance to read https://processwire.com/docs/front-end/output/, I'd suggest checking it out — learning about direct output and delayed output (and their differences) should clear some things up. As @szabesz pointed out above, there are ways to use MVC (or something very similar) on ProcessWire powered sites/apps. In my opinion MVC is great for a lot of stuff, but as always, by design ProcessWire makes zero assumptions: for some use cases simple direct output approach is quite enough, and makes things more straightforward (to build, but also to maintain) ?

v0.0.2: Just added all LESS files in /site/assets/RockSkinUikit to the files to monitor for changes. That means you can have a custom.less file in that folder and you'll get instant LESS support for the whole PW admin ? v0.0.3: I've changed the LESS variable prefix from @tm- to @rs- because I'm using @tm- for my frontend themes and RockLESS was mixing up some variables...

@ryan There is an issue with jQuery Timepicker Addon. https://github.com/processwire/processwire-issues/issues/1088 We have 1.6.1 in the core, but the latest version is 1.6.3, so maybe it's good time to update. Thanks.

--- Module Directory: https://modules.processwire.com/modules/privacy-wire/ Github: https://github.com/blaueQuelle/privacywire/ Packagist:https://packagist.org/packages/blauequelle/privacywire Module Class Name: PrivacyWire Changelog: https://github.com/blaueQuelle/privacywire/blob/master/Changelog.md --- This module is (yet another) way for implementing a cookie management solution. Of course there are several other possibilities: - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/ - https://github.com/webmanufaktur/CookieManagementBanner - https://github.com/johannesdachsel/cookiemonster - https://www.oiljs.org/ - ... and so on ... In this module you can configure which kind of cookie categories you want to manage: You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience. Currently there are four possible cookie groups: - Necessary (always enabled) - Functional - Statistics - Marketing - External Media All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ... When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax: <script type="text/plain" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The data-attributes (data-type and data-category) are required to get recognized by PrivacyWire. the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision. If you want to give the users the possibility to change their consent, you can use the following Textformatter: [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie. You can also add a custom link to output the banner again with a link / button with following class: <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button> I would love to hear your feedback ? CHANGELOG You can find the always up-to-date changelog file here.

You cannot have two pages that reference each other via "single" Page Reference fields: https://github.com/processwire/processwire-issues/issues/572 Also watch out for: https://github.com/processwire/processwire-issues/issues/1092 Workarounds include the Page IDs module or use "multiple" Page Reference fields instead of "single". I feel that the convenience of getting a Page object back as the value of a single Page Reference field is sadly outweighed by the frustration of these issues. I'd rather just get an ID that a Page object can then be loaded from if/when needed.

I used Canvas HTML theme which overlaid Bootstrap then added my own customisations which often overrode the Canvas theme CSS which overrode Bootstrap. The code bloat was stupid. Going back to pure SCSS/CSS with smarter use of CSS Grid, Flex & media queries. Can now place things where I want depending on screen size/device without unnecessary HTML for purely structural purposes, eg floated divs etc and much less CSS download. The page file size difference is incredible. Also trying to wean self off jQuery. That may take a little longer especially as PW is so dependent on it.

@joshua this looks like a really useful module thank you ?. Will definitely be giving this a try on our next project.

Not sure that you can modify edit URL in hook, but you can definitely override it in inherited class. Or just add custom method via hook and use it $wire->addHook("Page(template=your_template)::customEditURL", function(HookEvent $event){ return //// });

I guess I go about things backwards. ? I design the front-end based on content and what features are required, then I select the css framework that best suits it. Meaning, I'm lazy, and pick one where I have the least amount of work to do. I mostly use bootstrap, but have been using w3css with the past couple of projects.

Since modern browsers support flex and grid and most CSS3 specs, I also moved from using frameworks like BS to setting up things manually with my own, reusable scss partials and the JS libs that I need for a project. Also trying to move more and more to vanilla JS and kick jQuery. This way I get more streamlined assets. If I need to support old browsers (mainly IE11), I write some specific extra CSS to cater for them if need be.

I was a fan of Uikit (the same framework used in the PW backend) but nowadays I write all my css by myself, for the same reason you've mentioned above (using a framework is a tempting way to use default styles an call it a day). Even though I've not used the the new kid on the block (Tailwind, which claims to be "unopinionated", but I do not agree with that statement) I just prefer to be organized upfront with my scss partials and be consistent with styles during the prototype/design phase.

@ryan many thanks for that useful piece of code. I used it a lot lately, also on sites that changed during my locally work. Therefor I need to adapt it a bit to first check if the remote file is available (and the optional use of basic auth). So, if it is of use for someone too, here it is: // use assets from remote host on demand for local development copies $wire->addHookAfter('Pagefile::url', function($event) { fetchRemoteAssetsToLocalDev($event); }); $wire->addHookAfter('Pagefile::filename', function($event) { fetchRemoteAssetsToLocalDev($event); }); function fetchRemoteAssetsToLocalDev($event) { if(!$event->wire('user')->isSuperuser()) return; // only my personal preference $config = $event->wire('config'); if(!$config->Remote2Local) return; // I set the domain name of a remote host in the site/config.php $remoteHost = 'https://' . $config->Remote2Local; // I always use https these days $file = $event->return; if('url' == $event->method) { $file = $config->paths->root . substr($file, strlen($config->urls->root)); // convert url to disk path } if(!file_exists($file)) { // download file from source if it doesn't exist here, but exist on source $src = $remoteHost . '/site/assets/files/'; $url = str_replace($config->paths->files, $src, $file); $http = new WireHttp(); if($config->Remote2LocalBasicAuth) { // optionally use basic auth with credentials from config.php $http->setHeader('Authorization', 'Basic '.base64_encode($config->Remote2LocalBasicAuth)); } // check if file exist on remote host $http->head($url, [], ['use'=>'curl']); if('404' != substr($http->getHttpCode($url), 0, 3)) { // file is available if($config->Remote2LocalBasicAuth) { $http->setHeader('Authorization', 'Basic '.base64_encode($config->Remote2LocalBasicAuth)); } $res = $http->download($url, $file, ['use'=>'curl']); } else { // file is missing, log it $event->wire('log')->save('remoteFetch404', $url); } } } // use assets from remote host on demand for local development copies

@benbyf, I merged your question to the ProcessRedirects support board. Similar issue has been raised before, but since this module isn't really maintained anymore, currently your options seem to be... Switch to Jumplinks Try out the fork from @kixe: https://github.com/kixe/ProcessRedirects/tree/kixe In the long term switching to Jumplinks would likely be a better choice. Edit: I'm actually pretty sure that the fork won't fix this. The module creates unique key for redirect_from, which is varchar(256) — and if you're using utf8mb4, this is going over the limit (max key length is 191). I can see two solutions: update the module to limit the key length to 191 or remove said key altogether (though that would likely affect lookup speed negatively). TL;DR: switching to Jumplinks is indeed the sensible thing to do ?

I today integrated the multi-language support for all the config fields.