Leaderboard

Happy New Year! Today I’ve bumped the version on the dev branch to 3.0.170, and it’s quite a lot of updates. This post covers most of them. In this post, there’s also a question for you: what would you like to see in ProcessWire in 2021? https://processwire.com/blog/posts/pw-3.0.170/

v0.3.0 released, which adds dropdowns to Edit Role, Edit Permission, Edit Language, and when viewing a log file at Setup > Logs. @flydev ??, this version should also fix the problem you reported above.

OK I'm posting the simple workaround to this for anyone who may run into it in the future. Basically it is a missing page image which is causing this odd behaviour, feel free to try to replicate; I've got an image field on the page in question, image has been uploaded to the page via the API. Now somehow the image file has been deleted but the image info is still there in the PW page. When I access the image using the PW API it returns filesize 0 (no image file), debug data as follows: When I attempt the $image->size() function on image it causes the template to lose it's data and return to PW default template settings. This is not a one off, I can replicate repeatedly. The workaround (which I should not have to do really?) is to check the filesize before attempting a resize: Perhaps it could be considered good practice to check the filesize prior to operations on the image but not doing so should not result in the template blanking it's settings. I'm guessing this situation of a missing image is either very rare or I've run into something odd on my particular instance as I can't find any mention of others encountering this issue. The exact same code and database under v2.7 runs fine for this page,

Brilliant - thank you!

Could you please add the steps you are following to reproduce the problem? I'm trying to reproduce it but am not able to. What I'm doing is: Template settings have slashUrls set to false (0). I upload an image to a "single" image field and save the page. I delete the uploaded image file from /site/assets/files/1234/ I check the filesize of the PageImage to confirm that PW can not locate the file. I call the size() method on the PageImage with the now missing file. I tried with both the GD and ImageMagick sizer engines. I check the slashUrls setting of the template. So far I don't experience any changes to the template settings of the page.

Done, https://github.com/processwire/processwire-issues/issues/1298

I think this is a helpful post for anybody new to hooks: https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/?tab=comments#comment-158164

Hi @Robin S Since the last update (0.2.0) I get this exception when I set a custom hook : Fatal Error: Uncaught TypeError: Argument 1 passed to BreadcrumbDropdowns::pageEditBreadcrumbs() must be an instance of AdminThemeUikit, instance of AdminThemeCanvas given, called in site/modules/BreadcrumbDropdowns/BreadcrumbDropdowns.module on line 117 and defined in site/modules/BreadcrumbDropdowns/BreadcrumbDropdowns.module:221 #0 site/modules/BreadcrumbDropdowns/BreadcrumbDropdowns.module (117): BreadcrumbDropdowns->pageEditBreadcrumbs(Object(AdminThemeCanvas)) #1 wire/core/Wire.php (397): BreadcrumbDropdowns->modifyBreadcrumbs(Object(HookEvent)) #2 wire/core/WireHooks.php (927): Wire->_callMethod('modifyBreadcrum...', Array) #3 wire/core/Wire.php (465): WireHooks->runHooks(Object(AdminThem (line 221 of site/modules/BreadcrumbDropdowns/BreadcrumbDropdowns.module) This error message was shown because: you are logged in as a Superuser. Error has been logged. Sorry I didn't got the time to investigate. I am using the custom theme AdminThemeCanvas.

remove this comment : https://github.com/processwire/processwire/blob/master/htaccess.txt#L173

Hi @cyberderf, Welcome to the forum. It seems like a url rewrite problem. Please check the following: 1. Does .htacccess file exist in your web root folder. You need to rename the htaccess.txt file to .htaccess. 2. Check your apache conf file and see if mod_rewrite is enabled. Gideon

I've updated Combo to use @Robin S strategy for moving the subfields around the page editor and posted it in the ProFields download thread as v2. The definition is available for any Combo subfield and it's very simple, but I figure it's something at least to start with.... it's working and ready to use. It does use a datalist-based autocomplete, so you don't necessarily have to remember all your field names. Thanks Robin S. for the idea on how to make it work, it seems to be a clean and reliable way to do it.

When I talk about the goal of ProFields being to reduce the number of fields necessary, I don't mean that to stretch into “at all costs”, going beyond what would be logically related in a fieldset or object, or stepping outside the responsibility and purpose of fields. All of the ProFields are focused on reducing field usage for cases where logically grouping them makes sense: visually, semantically, structurally. ProFields are not intended to hack around, change the meaning of, or blur the lines of what’s provided by ProcessWire. ProFields are designed to work with ProcessWire, using its interface and architecture to maximum effect, extending it in the way it’s designed to be extended. There’s nothing that a field like Combo (or any other) could do to make its subfields start pretending they are regular fields. So it’s not even a request I can entertain because it’s simply not possible for a Fieldtype to get involved in that. Don’t look for any ProField (or any field) to do this, because that’s well outside what a field can do technically, and outside of its responsibility or control. If you find yourself having this interest for subfields in a particular field tossed around in different locations of the template, take a step back and ask why. Then consider, this is what ProcessWire fields do, it’s what they are for, and they do it without breaking the borders of responsibility or blurring any lines of what they are. There’s nothing wrong with using regular ProcessWire fields for their intended purpose. Neither Combo nor any of the ProFields are meant to replace that. ProFields answer specific things, they are not intended to replace the template-field relationship, nor could they. Use ProFields where they cross over with a specific need they answer, and skip them when they don't. I understand subfields are cool and popular now, but fields are still where it’s at. Templates are still templates and fields are still fields. A Combo field is also still a field (not a template), and a subfield is still a subfield (not a field). I’d drive myself mad and have an unmaintainable code base if I started mixing up these things or breaking their relationships. I’d like to better understand why you would want to do any of this stuff in the first place (versus just using Fields how they are supposed to be used). Is it because you want them to be stored together behind-the-scenes so that they can be searched as one? Is it because it’s less tables to look at in your DB or less fields to see in your Setup > Fields? Is it because you think it might use less memory/resources that way? Or something else? I think if I understand what the underlying point of this is, that would be helpful. If it turns out that there really is some significant and real benefit in doing this, that can’t be met by using the system as intended, then I’d be interested in looking into it further. But it’s something that would have to be considered in the core and managed by the template (fieldgroup component). That’s because a Field getting involved in the responsibilities and relationships of templates to fields would be bad architecture and a broken system. Whereas, if the core provided an interface where a Field can specify which of its subfields are allowed to be visually “detached” in the page editor, and the template and page editor know of and read that interface, that’s where the architecture could work (no responsibilities broken). The Uikit theme is not a requirement of Combo, so if you find Reno isn't working, that's likely just a 1st beta version glitch that I need to work out. I'll get that figured out.

Well, hello somebody! Look at what I've stumbled upon ?. Tailwind Starter Kit A beautiful extension for TailwindCSS. Tailwind Starter Kit is Free and Open Source. It does not change or add any CSS to the already one from TailwindCSS. It features multiple HTML elements and it comes with dynamic components for ReactJS, Vue and Angular. Yes and vanilla JS as well! (currently, 16 dynamic components.). License: MIT GitHub: https://github.com/creativetimofficial/tailwind-starter-kit Site + Demos: https://www.creative-tim.com/learning-lab/tailwind-starter-kit/ A tutorial on YouTube. I haven't dug in deep yet (e.g. purge/tree shaking, etc). @Jonathan Lahijani. What do you think? ?

Had this same issue today, ie get the customised label for a page/template field and tried all the above. They all returned the original field label and couldn't find any reference to the 'true' option when getting 'fields' or 'field' in the API Docs. Maybe PW has moved on or more likely, I missed something. Anyway, what did work for me was: $page->getField("body")->label; https://processwire.com/api/ref/page/get-field/

@SamC it's really as simple as that: https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#new-conditional-hooks Update 2022: $wire->addHookAfter('Pages::saved', function(HookEvent $event) { $page = $event->arguments('page'); bd('page saved'); bd($event, 'event'); bd($event->object, 'event->object'); bd($event->arguments(), 'event->arguments'); }); in the beginning it can be a little confusing when to use event->object, event->arguments and event->return but with the help of tracy you can quickly bring light into the dark: add the code above to the tracy console, set the radio on the right to load it on "ready" (same as placing the code in the site/ready.php file) and save any page: $event->arguments('page') is the same as using $event->arguments(0) that you will see very often and in the tracy dump you see that 0 is simply the key for the first argument in that hookevent. you can also collapse the "data" property of the hookevent and you would see the same: You can also use your IDE to quickly find what the HookEvent is returning/containing in which hook. Let's take the common saveReady hook as an example: We know that the hook is attached as Pages::saveReady (eg because we have read that somewhere) That means that the hook is part of the "Pages" class, which is located at "/wire/core/Pages.php" - that's easy to find out using CTRL+P in VSCode: Searching for "___saveReady" lets us find the corresponding method: Now we see, that we have ONE "arguments", being Page $page - this means $event->arguments(0) would return the page being ready for saving $event->object would be the class, here "Pages" $event->return is the return value of that method, here $data (line 1739) Edit: There's some additional explanations in this post: https://processwire.com/talk/topic/27248-pagestrashtemplatefoo-vs-pagestemplatefootrash/?do=findComment&comment=224659 #search afraid of hooks