Leaderboard

@Pete From this side, my wife's job is one that requires her to be on phone/video meetings most of the day, so she's got to lock herself away from us to focus on that, and the kids are mostly with me during the day. I'm good at focused attention, but not great at changing gears, so I'm still learning. My days used to be just coffee and code. Now things are much more diverse, here's a typical day: wakeup, breakfast, coffee, code, kids wakeup, resolve dispute, make breakfast, coffee, code, hear that TV is on, check in to make sure kids are doing school work, turn off TV, say “get back to school work”, try to figure out something with google classroom, worry about whether I'm doing enough to keep kids focused on school, code, get icloud request to approve download of some game on iPad, tell kids to “get back to work”, explain why several times, answer questions about school work, hear music from some game and decide to let it slide, 1 email, cycle power on router because wife says she can't connect to important video call, code, resolve kids dispute, put 1 kid in timeout, legos, clean up spill, 1 email, slack message, cook lunch, coffee, code, worry about whether kids are spending too much time on screens, phone call, reset wifi because daughter says Roblox won't connect, then work a little more, click the "snooze" button on a dozen emails so they return tomorrow, take kids outside to play while I work on house or yard, ride bikes, cook dinner, eat, netflix, cleanup dinner, go to bed, feel thankful to be healthy, sleep well. I'm definitely still adapting here, but I can't complain about the new normal because having everyone under one roof is comforting, especially at times like this. And while it's harder to get work done, it's mostly still getting done and I just feel thankful to be staying busy. Also, knowing there's nowhere to go but home, life is simpler in many ways.

It took me weeks to adapt mentally. I'm not sure why, I work from home and my wife looks after the kids at the moment so I'm in a better position than many, but the whole situation in the wider world made me lose my work mojo for a while. Definitely got it back this past week though - back on track finally with projects ? Hope everyone here is as well as they can be in the circumstances.

Everyone, please be aware of this bug in AdminOnSteroids (https://github.com/rolandtoth/AdminOnSteroids/issues/118) that breaks CkEditor fields with this new PW version. You can easily patch AOS to fix it, but be sure to test before you let your site editors find the problem ?

This is the way ... now Shopify .. then Processwire + Padloper 2 (when released)

Here’s a brief update on what’s new in the core since last week. Next week I’m going to compile a more complete overview of everything that’s in 3.0.154 (and more) and put it in a blog post. I wanted to do that today, but my kids have needed a lot of help with various things today (and this whole week actually) with all of this online school stuff and I’ve run out of time. We're a few weeks in and school is cancelled for the rest of the year due to the coronavirus (likely the same around the world). I'm still learning how to adapt to kids around all day and needing attention, but overall it's nice to have the family around more even if it is sometimes hard to get work done. So I’ll keep this sort of brief, and get into more details next week. Several updates were made to the core/LanguageFunctions.php (language functions) file, with biggest being the option to programmatically replace translation text (whether multi-language support is installed or not), useful for very easily updating core/module output to say exactly what you want, and without needing to install multi-language modules. No longer do you need to use various hooks to change text in one module or another. Also moved the __('text') configuration options to dedicated functions which makes it more clear to use, as well as much better for documentation purposes: wireLangEntityEncode(), wireLangTranslations(), wireLangReplacements(). You'll see these new functions in our docs by next week. More details and examples of these in action in next week’s blog post. The CKEditor version has been upgraded from 4.12.1 to 4.14.0. To see what’s changed, see the release notes for CKEditor 4.13.0, 4.13.1 and 4.14.0 here. There’s actually quite a lot here in terms of additions and fixes. Note especially the two security related fixes in 4.14.0 (though I think only the first may be applicable to us). While it looks like a rather unlikely combination of factors needs to come together, and with just the right person, it’s good to be aware of nevertheless. Of note is that these particular cases are entirely client side, before PW ever gets to see or filter the content, so this is something that only a CKEditor upgrade can fix. Updated the core Debug class to use PHP 7.3’s recommended hrtime (high resolution time) for debug timers, rather than microtome. This is only available in PHP 7.3 and newer. As far as I can tell it produces identical results to microtome (as far is our timers go) but the PHP documentation page indicates hrtime is what we should now be using, so that’s what we’re going with. I also did a little refactoring and minor improvements in the Debug class as well. Updated ProcessWire’s Inputfield rendering system so that you can customize markup by matching a field by name, and without hooks. This essentially takes part the Inputfield customization system developed for LoginRegisterPro and brings it into the core. This opens up a lot more customizability for those that want it. Various resolutions of GitHub issue reports, with more on the way. The above are just updates from the last week, but there’s plenty more in 3.0.154 as well. See ProcessWire Weekly #309 for details on Image and file field updates, new $database->columnExists() method and new Selectors::getOperators() method, and more. There are also the new expanded file and image properties, as discussed in #308 and the last blog post. Thanks for reading and I hope you all have a great weekend!

FYI, the core has built-in support for relative time strings: https://processwire.com/api/ref/wire-date-time/relative-time-str/

Sorry - didn't get that you are talking about Fieldtype/Inputfield modules! They are definitely not that easy to grasp! ? It also took me really long to understand how they work and what the important parts are... The problem is that it's quite easy once you know how things work, but it's quite hard to understand what's going on when and where when you look at the code of a finished module (like the events fieldtype that was intended to be a tutorial module...). Having said that, I'm still not sure if you really need a fieldtype/inputfield module. Also a basic module comes with the benefits mentioned above and it's as simple as that: class YourModule extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'YourModule', 'version' => '0.0.1', 'summary' => 'Your module description', ]; } function evaluate_condition($condition, $pageId) { // your code here } } Then you can call your function: $modules->get('YourModule')->evaluate_condition('foo', 123); That's very little effort for lots of benefits. Maybe you don't even need to create a full blown Inputfield/Fieldtype module. You could maybe just make it autoload and add a hook to your module: class YourModule extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'YourModule', 'version' => '0.0.1', 'summary' => 'Your module description', 'autoload' => true, // added this ]; } public function init() { $this->addHookAfter("Inputfield::render", function($event) { $event->return .= "<div>My modified Inputfield</div>"; }); } function evaluate_condition($condition, $pageId) { // your code here } } Or even better, since you always check the condition for a single page, attach the method to the page object: class YourModule extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'YourModule', 'version' => '0.0.1', 'summary' => 'Your module description', 'autoload' => true, ]; } public function init() { $this->addHookAfter("Page::evaluate_condition", $this, "evaluate_condition"); } function evaluate_condition(HookEvent $event) { $page = $event->object; $condition = $event->arguments(0); // your code here // instead of return 'foo' use $event->return = 'foo' } } Then you can do this on any processwire $page $page->evaluate_condition("foo"); PS: The boilerplate code for every module is always the same. It might look frightening at first sight, but using vscode snippets for example it's really just typing "pwmodule" and filling in the placeholders (like shown in the gif above). https://marketplace.visualstudio.com/items?itemName=baumrock.pwsnippets

IMHO it's almost always worth building a module: You can share it across projects You can fix bux and add features in a central place You can easily share it with the community You can add documentation easily via readme file And it's really almost no extra effort:

Yes, edited right before your answer ?

What kind of field is "entryPages"? I suppose an integer field due to the fact you're comparing with the user->id. And in which situation a user would write inside that field an exact id? ...or, entryPages is a page reference filed, but since it's plural you are dealing with an array of pages, so comparing a single id with an array would never match?

Hello and thanks for your work! is this still being maintained? Last changes on github dev repo are 16 months ago.

Yes, I'm well aware that it is completely valid to have inputs and such outside of a form element and with email address EMO breaks the markup but I thought this was not the issue in your case since there was already previous post from creativejay about problems with FormBuilder and you also mentioned that EMO shoudn't touch values of form elements but you were literally talking about inputs and such, not the form element itself. Sorry about that. There are also another technically valid situations where EMO fails e.g. like having an email inside data attribute. Generally it is kind of compicated topic to automatically replace email address by new node in every possible case without breaking things. Anyway, current state where EMO skips whole content inside form element is not ideal since there are many cases where you can have email addresses inside form where they should get obfuscated but currenly are not. Like the one in my previous form example where email inside p element should be touched but it's not. That said maybe we should remove the form element completely from ignored elements and concentrate only at form elements (what you suggested actually) like input, option and textarea where most likely touching email addresses will give us headaches. I'll look into it.

Some introduction... This module is experimental and there are probably bugs - so treat it as alpha and don't use it on production websites. I started on this module because there have been quite a few requests for "fake" or "invisible" parent functionality and I was curious about what is possible given that the idea sort of goes against the PW page structure philosophy. I'm not sure that I will use this module myself, just because I don't really see a long list of pages under Home (or anywhere else) as untidy or cluttered. I would tend to use Lister Pro when I want to see some set of pages as a self-contained group. But maybe others will find it useful. At the moment this module does not manipulate the breadcrumb menu in admin. So when you are editing or adding a virtual child the real location of the page is revealed in the breadcrumb menu. That's because I don't see the point in trying to comprehensively fool users about the real location of pages - I think it's better that they have some understanding of where the pages really are. But I'm open to feedback on this and it is possible to alter the breadcrumbs if there's a consensus that it would be better that way. Virtual Parents Allows pages in Page List to be grouped under a virtual parent. This module manipulates the page list and the flyout tree menu to make it appear that one or more pages are children of another page when in fact they are siblings of that page. Why would you do that instead of actually putting the child pages inside the parent? Mainly if you want to avoid adding the parent name as part of the URL. For example, suppose you have some pages that you want to be accessed at URLs directly off the site root: yourdomain.com/some-page/. But in the page list you want them to be appear under a parent for the sake of visual grouping or to declutter the page list under Home. Example of how the page structure actually is Example of how the page structure appears with Virtual Parents activated How it works This module identifies the virtual parents and virtual children by way of template. You define a single template as the virtual parent template and one or more templates as the virtual child templates. Anytime pages using the child template(s) are siblings of a page using the parent template, those child pages will appear as children of the virtual parent in the page list and tree menu. You will want to create dedicated templates for identifying virtual parents and virtual children and reserve them just for use with this module. Features Adjusts both page list and tree flyout menu to show the virtual parent/child structure, including the count of child pages. Works everywhere page list is used: Page List Select / Page List Select Multiple (and therefore CKEditor link dialog). Intercepts the "Add page" process in admin, so that when an attempt is made to add a child to a virtual parent, the child is added where it belongs (the next level up) and the template selection is limited to virtual child templates. Intercepts moving and sorting pages in the page list, to ensure only virtual children may be moved/sorted under the virtual parent. Superusers have a toggle switch at the bottom of the page list to easily disable/enable Virtual Parents in order to get a view of what the real page structure is. Usage Install the Virtual Parents module. In the module config, enter pairs of parent/child template names in the form virtual_parent_template=virtual_child_template. If needed you can specify multiple pipe-separated child templates: virtual_parent_template=child_template_1|child_template_2. One pair of template names per line. There is a checkbox in the module config to toggle Virtual Pages on and off, but it's more convenient to use this from the page list. Notes It's important to keep in mind the real location of the virtual child pages. This module is only concerned with adjusting the appearance of page list and tree menu for the sake of visual grouping and tidiness. In all other respects the virtual children are not children of the virtual parent at all. It's recommended to select an icon for the virtual parent template (Advanced tab) so virtual parents are marked out in the page list as being different from normal parent pages. Do not place real children under a virtual parent. There is some protection against this when moving pages in the page list, but when it comes to changing a page's parent via the Settings tab the only protection is common sense. https://github.com/Toutouwai/VirtualParents

Created an issue and pull request with a fix https://github.com/processwire/processwire/pull/91 https://github.com/processwire/processwire-issues/issues/385

Hi! Look for Custom Editor JS Styles Set in the field configuration and enter a path for .js file. In this file you can define your custom styles like this: CKEDITOR.stylesSet.add('mystyles', [ // Block-level styles { name: 'Heading 1', element: 'h1'}, { name: 'Heading 2', element: 'h2'}, { name: 'Heading 3', element: 'h3'}, { name: 'Introduction', element: 'p', attributes: { 'class': 'introduction'} }, // Inline styles { name: 'Link button', element: 'a', attributes: { 'class': 'button' } }, { name: 'Highlight', element: 'span', attributes: { 'class': 'highlight' } }, // Object styles { name: 'Stretch', element: 'img', attributes: { 'class': 'stretch' } }, ]); Also make sure you have Styles toolbar item enabled.