Leaderboard

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.

Here's a small new module that started as a spinoff of a memcache proof-of-concept. Cache your strings and partials in-memory using Redis as a backend. CacheRedis All you need is a running Redis database. The module supports connection through regular TCP, over TLS and via unix domain sockets. Host and port are configurable, and authentication is supported too. Here's a screenshot of the module configuration options: I'll not go into too many details about the usage, you can see everything explained in the README on GitHub, and just highlight the most important points. When the module is active, you'll have a wired $redis variable, which means you can reach the module as $redis, wire("redis") or within Wire classes / modules as $this->redis. CacheRedis is strongly influenced by WireCache, and its usage is (hopefully) straight forward. // Store an entry in the cache under the given key name with the given value: $redis->store("cached_value_number_one", $expire, $value); // Retrieve a value from the cache $value = $redis->fetch($key); // Delete a cache entry $redis->delete("my_other_cached_value"); // Clear the whole cache $redis->flush(); // Retrieve a value from the cache, and if not found, create it through the given function // and store it with a lifetime of 5 minutes (300 seconds) $value = $redis->fetch($key, 300, function() use($page) { return "Page last changed on " . strftime('%m/%d/%Y %H:%M', $page->modified | $page->created); }); // Render a file using wireRenderFile and store it in the cache. // We'll pass a selector as the expiry value so this cache gets // emptied every time a page matching the selector is saved. $news = $redis->renderFile("partials/news.php", 'template=blog-post', ["page" => $page]); The module is still very crude work in progress, but I hope some of you feel daring, try it out and let me know in case anything breaks. Have fun!

I've put huge amounts of work into that module in the last few days. I had to take two steps back to take the next step forward: It turned out, that I needed a more robust and flexible setup when dealing with date ranges. And what I did is - thinking about it now - quite obvious: A RockDaterange now consists of two RockDatetimes. I've put a lot of effort into developing the RockDatetime module. It is already available on Github and has lots of examples and docs in the readme: https://github.com/BernhardBaumrock/RockDatetime Highlights: // 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()) ... // 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 I've also totally rebuilt the date parsing engine! Finding pages using the API $tpl = "template=event"; $pages->find("$tpl,range=2020"); // find all events in 2020 $pages->find("$tpl,range=2020-02"); // find all events in Feb 2020 $pages->find("$tpl,range=2020-02-26"); // find all events on 26. Feb 2020 // other possible selectors $pages->find("$tpl,range=2020-02-10 - 2020-02-20"); $pages->find("$tpl,range=2020-02-10 7:30 - 17:30"); $pages->find("$tpl,range=2020-02-10 7 - 9"); $pages->find("$tpl,range=2020-02-10 12:00 - 2020-02-20 18:00"); // find events in Feb 2020 sorted by range duration $pages->find("$tpl,range=2020-02, sort=-range.duration"); Creating pages using the API $p = new Page(); $p->setAndSave("range", "2020"); // from = 2020-01-01 00:00:00 // _to = 2020-12-31 23:59:59 // to = 2021-01-01 00:00:00 $p->setAndSave("range", "2020-12-24 16:00 - 18:00"); // from = 2020-12-24 16:00:00 // _to = 2020-12-24 17:59:59 // to = 2020-12-24 18:00:00 Formatting in action: // left column echo $range->format(['date' => "%A, %d.%m.%Y", 'time' => '']); // right column echo $range->format(['date' => "%a, %d.%m.%Y"]); Note that the last date does NOT show "07.03.2020 09:00 - 07.03.2020 12:00" - since the event ends on the same day as it starts we don't show that date again. RockDaterange will take care of all those tedious details!

Tailwind user here! I'd definitely recommend checking Tailwind out. Where it really shines, in my opinion, is any kind of rapid development / fast prototyping: add a bit of (semantic) HTML and sprinkle it with a bunch of classes and you'll have a good looking site in no time. One downside, though, is that when you're building something really big, it can easily get out of hand unless you set some ground rules / constraints for yourself in terms of how many spacing variations, colours, etc. you're going to use. If you don't, you're going to end up with an end product that looks inconsistent, is a lot of work to maintain/refactor, etc. ? As a matter of fact Tailwind is unopinionated: the framework doesn't come with any pre-built components, so it's entirely up to you what you build with it. Only features in Tailwind that could be considered somewhat opinionated would be things like the default colour palette, shadow styles, spacings, etc... but you can easily override all that. And for those who actually prefer pre-built components, there's a new (commercial) project just being launched called Tailwind UI, which is essentially a library consisting of hundreds of Tailwind based front-end components ? (Also: https://tailwindcomponents.com/. That's the free alternative / predecessor to Tailwind UI.) ... although, all that being said: for my personal projects I've mostly preferred vanilla CSS/JS and a BEM(-ish) structure. Nice and simple ?‍♂️ Back in the day I used to be a big fan of Foundation, but nowadays I find that type of framework mostly a nuisance. Basic things like grids are by now (mostly) solved in CSS, so unless you're intending to use the out-of-the-box components provided by the framework to dictate how you build your front-end, I don't see much sense in going that way. To each their own, though; this sort of thing is largely a matter of taste and habit ?

Admin on Steroids has an option where you can map CTRL + S to the save function. That way you don't even have to care about the button's position (but might be a bit overkill if you only need this module for only this feature).

@bernhard I know about that and drew a lot of inspiration from it in some ways, but in other ways it doesn't play by ProcessWire's rules. It also doesn't have dynamic content loading yet (although YooTheme is working on it). Also, it's using WordPress's "old" customizer which will ultimately be replaced with Gutenberg. Also, YooTheme comes in as a THEME, not a plugin, which is somewhat strange. What I showed you on our call a few months ago has gone through a big transformation and evolving. Still lots to do before I make a peep about it.

Reminds me of a particular CMS ? This is equally true when using BEM-like methods. Even if you are using content-agnostic components (hint) it is very hard to maintain CSS in large projects. Especially in teams where more devs are involved. With the rise and rise of Vue and React this becomes somewhat more manageable if you scope your css to your component, but still... That being said: I'm currently working on a large project for myself and I am speeding up my development flow faster than I could imagine using Tailwind. And I used to be anti concering utility classes ?.

I only ever use BS or Foundation just for the grid, mixins and helper / utility classes (.visuallyhidden et al) + normalize (S)CSS. There's nothing wrong with it, and I don't understand people who claim that "every site built with BS looks the same" (or that is has to). It's just a tool. It doesn't dictate anything. As for components, I'm cherry-picking and choose the "best in class" (e.g. PhotoSwipe for lightboxes, Flying Focus) or build my own. An accordion or tab component is a trivial thing to build, and at some point (if you have a very custom design) it's easier than tweaking an existing solution. But of course - it all depends... on budget, deadlines etc.

I recommend the modern CodyFrame framework, and the main reason is that it has separate elements, i.e. you add to the page what you need as Components, so there is no mess in the code, and the page should load faster, the size of the files will not be huge, yes as in most major CSS frameworks. There are also other reasons, such as the Global Editor ( GLOBALS ), thanks to which your website will not look like hundreds of others based on the same CSS frameworks (you can customize many elements such as colors, typography, buttons, forms ). Plus many basic Tutorials that you can start with. You can also see this Site Profile, which can be a good start to familiarize yourself with this framework.

A little hack like this for site/ready.php might be enough for that (only tested on desktop and not perfect when it comes to alignment): $this->addHookAfter('ProcessPageEdit::execute', function($event) { $event->return .= "<script> $('#pw-content-head-buttons').css('position', 'fixed'); $('#pw-content-head-buttons').css('right', '5%'); </script> "; });

Thank you so much for all your efforts in putting this together! I'll be using this soon to replace date range logic in 2 live projects that deal with events.

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.

Just discovered a technique that can save you lots of time and headache! Debugging can be a pain when creating PDFs, but it gets a lot simpler if you use this handy trick. I'm hooking into pageNotFoud to create the pdf: $this->addHookBefore('ProcessPageView::pageNotFound', $this, 'renderCalendar'); If everything goes right, the calendar shows up in the browser: But there's one problem: We don't know anything about errors, warnings, etc. Logging them into the pw logs is a pain compared to the Tracy Debugbar, so here's how you can have both - the generated HTML of the PDF and the debug bar: We create the PDF BEFORE the 404 is thrown, but we create the HTML AFTER the 404: $this->addHookBefore('ProcessPageView::pageNotFound', $this, 'renderCalendar'); $this->addHookAfter('ProcessPageView::pageNotFound', $this, 'renderCalendarDebug'); /** * Render PDF calendar */ public function renderCalendar(HookEvent $event) { $url = $event->arguments(1); $cal = $this->modules->get('RockPdfCalendar'); // check url etc ... // generate the PDF $pdf = $cal->pdf; /** @var RockPdf $pdf */ ... $title = 'Kaumberg Kalender ' . date("Y-m", $start); $pdf->set('setTitle', $title); $pdf->write($cal->render()); // if html get parameter is set we return the html output $this->session->calHTML = null; if($this->user->isSuperuser() AND $this->input->get->html) { $this->session->calHTML = $pdf->html(); return; } $pdf->show("$title.pdf"); die(); } /** * Output calendar for debugging * @return void */ public function renderCalendarDebug(HookEvent $event) { if($this->session->calHTML) $event->return = $this->session->calHTML; } ?

@LAPS @J_Szwarga i updated config file finder and pushed new version of module. You can update your module ! Please let me know if you have same issue. @bernhard i updated finder https://github.com/trk/FieldtypeFontIconPicker/blob/master/FieldtypeFontIconPicker.module#L46 as your recommend, if it success on this module. i will apply same function for my Mystique module.

This week we’ve got a couple of really useful API-side improvements to the core in 3.0.151, among other updates. First we’ll take a look at a new $config setting that lets you predefine image resize settings, enabling you to isolate them from code that outputs them, not unlike how you isolate CSS from HTML. Following that, we’ll introduce and show you how to use a handy addition to our static language translation functions. If you’ve ever come across the term “abandoned translation”, you’ll really like what this adds— https://processwire.com/blog/posts/pw-3.0.151/

Hi guys, I was very excited for this module, but my life took a huge direction change and I no longer have the time to invest in module development. I am gonna leave the files here. You guys can take it and run. Maybe there might be something useful here. Maybe not. I still think it's a good idea to do drag and drop modal building in PW. So hopefully one day something like that can come to light. I love this community and I love ProcessWire. Live long and prosper. - Joshua Designme 2.zip

Just my five cents: this project seems like something that would be very useful without any support for recurring. I'd love to get my hands on this feature, and I'm pretty sure I'll never even need that latter part. In fact more commonly I've needed reoccurring events (hope that makes sense; basically I mean events with multiple, manually specified dates rather than a set of rules to govern when and how often they should recur). Recurring rules can get extremely complicated: "this event occurs every Friday between January and August except specific days x, y, and z — and then it also occurs on this particular Wednesday and that Tuesday there, but on those days there needs to be this additional note on the content". Done that a few times, but I try my best to steer away from those implementations. It's very rarely worth the hassle. In my experience lot of that mess can be circumvented by allowing multiple dates (or date ranges) for one event ?

Thanks for everyone helping me out here. I found a solution, but if anyone could explain why this works all of a sudden, i would be very grateful. The Code i posted above, all i need to do, was a conditional check if the RepeaterMatrix isnt NULL, then the getNew() call worked: site/ready.php <?php namespace ProcessWire; if(!defined("PROCESSWIRE")) die(); $pages->addHookBefore('Pages::added', function (HookEvent $event){ // Fetch Page Data $data = $event->arguments(0); // Fetch Page Object $page = $this->pages->get($data->id); // Check if the RepeaterMatrix is not NULL if($page->product_matrix != null) { // Save the new RepeaterMatrixPage im going to add, in a Variable $newItem = $page->product_matrix->getNew(); } // Safetycheck if i got anything if($newItem == null) return; // Set RepeaterMatrixPage Type, so the Correct Type of Item gets created and the Data gets saved in the Correct Fields // The Field Types are in the Order of their creation in the RepeaterMatrix Field, and they beginn counting at 1 $newItem->repeater_matrix_type = 2; $newItem->product_properties_title = "Zusätzliche Informationen"; // Save the Item, as it is a Page $newItem->save(); // Add new Children to the RepeaterMatrixPageArray $page->product_matrix->add($newItem); // Save newly created Page again, so the RepeaterMatrix Items are saved in the List. $page->save(); }); I dont know why this works all of a sudden, but im glad it does. kind regards Marc H.

Sure – where I work at we did exactly that, and haven't looked back since. First of all, it's important to understand that at it's core ProcessWire is a (web) application framework. We prefer to call it a content management framework, but that's not very far from what most web applications do: they store, process, and output content. The way I see it, the main difference to so-called traditional frameworks is that modelling and handling data is a built-in feature, not something you have to reinvent on a case-by-case basis. I have rebuilt a couple of old projects from the scratch using ProcessWire, and in all of those cases this has saved me a lot of time and made most of the model layer obsolete. Before we started using ProcessWire we were doing sites with another CMS and custom applications with Zend Framework. At the beginning I had this idea that we would use ZF for "apps" and ProcessWire for "sites", but in just a few short months we realised that there just wasn't anything we could achieve with ZF that couldn't be done, usually with less work, with ProcessWire. Sure, sometimes we pull other libraries into the mix, but that's not a shortcoming; in my opinion it's just good design Regarding some of the things that have been mentioned here: One thing I was originally missing from Zend Framework was a clearly defined structure. Built-in "one file per template" concept is great for simple sites, but that's just about it. This is why I built the original version of my MVC project. It's not perfect, but it has served us well for years. To get most out of ProcessWire you really should be using it's data modelling abilities. Sure, you can still mock up your own data structures and write SQL to fetch content from the database etc. but that's kind of missing the point: ProcessWire makes data modelling a breeze and the selector engine is both flexible and secure. Some users prefer to build custom management panels, but in my opinion that's another thing you should try to avoid. ProcessWire's admin GUI is flexible and extendable (see Process modules), and again: in most moderately sized projects it can easily save you days of work. For routing you can use page URLs, but I'd also suggest looking into URL segments. For me, coming from the world of Zend Framework, templates are a lot like controllers and URL segments make it easy to implement the concept of actions Try not to invent your own access management system. ProcessWire has a very good implementation of RBAC already in place, and if you need more flexibility, I'd suggest looking into modules such as Dynamic Roles and/or User Groups. Rolling out your own solution is risky, tends to cost a lot, and just generally speaking is a very bad idea. Form validation has been mentioned twice here already. I don't have much insight into this, except that in the beginning we used to build forms using Zend Form, which has it's own validation built-in. That was always a bit tricky (not because of ProcessWire), and these days we use Form Builder for pretty much every form-related need. Sure, it's a commercial module, but it has saved us so much time that the price is absolutely not an issue. In my opinion the answer to your original question is yes and no: ProcessWire can't substitute an application framework because it is an application framework

@netcarver Brother, that's EXACTLY what I did! I followed the above link and used this little code. $git rm --cached That solved it. Thank you!

I checked @dadish profile, everything during instalation is OK, but doesn't work any page/subpage and admin panel. I got 404 error. Everything from server side is ok - I can install default profile and all works OK. Maybe missing some files? @louisstephens thank you for your post.