Leaderboard

Greetings from the sunny covid hotspot state of Georgia, where we haven’t left the house since March. And now getting ready for the kids to start a new school year from home with virtual learning. Everyone delivers everything now, so there’s no need to go out to a grocery store anymore (or go anywhere). I live about a mile from the CDC, so our school district has more kids with parents working at the CDC than any other. That gives me some comfort, knowing that I won’t be sending my kids back to school until the experts at the CDC are willing to; when it’s really and truly safe. Though I don’t think it’s going to be safe for a long, long time. The US is a rudderless ship right now, so we just have to ride it out. Thankfully, we’re all staying safe and keeping busy. The kids are building houses in Roblox (an online game addiction they have), we’ve converted our yard to be a summer camp, and converted the basement to be a gym, while we clear more space to start building out a massive N-scale train set—my 3 locomotives still work perfectly, even after 35 years of storage. And I’ve been learning how to manage chlorine and PH in an inflatable kids pool that keeps the family cool in the hot weather. The kids miss school and other activities, my wife misses being at her office and people she works with, and we all miss our friends and family, but it’s the way things are now, and I’m just grateful to have my immediate family home and safe; and in place where we can ride out the storm. I’m also really glad that I can work on the ProcessWire core and modules for pretty much the entire work day, and enjoying coding as much as I ever have; feeling great about where ProcessWire is and where it’s going, thanks to all of you. I’ve been working on the latest ProCache version the entire week, so not many core updates to report today other than some new hooks added to the Pages class (they are hooks that the new ProCache can use as well). I’d hoped to have this version of ProCache finished by now, but I keep finding more stuff to improve, so decided give it another 2 days of work and testing, and if all looks good, it’ll be ready to release, which will be next week. This version is essentially a major refactor, where just about every line of code has been revisited in some form or another. But if you are already a ProCache user, you’ll also find it very familiar. While I don’t have it posted for download today, below is a brief look at what’s new. Completely new .htaccess rules (v2) that take up a lot less space, especially when using multiple hosts, schemes or extensions. Ability to choose .htaccess version (v1 or v2). ProCache now creates an example .htaccess-procache file that you can rename and use or copy/paste from. ProCache now has a built-in URL testing tool where you can compare the non-cached vs. cached render times. New setting to specify how ProCache delivered URLs should respond to trailing vs. non-trailing slashes in URL. Significant refactor that separates all ProCache functions into separate dedicated classes. Improved custom lifespan settings with predefined template lines. Improved behavior settings with predefined template lines and simpler letter (rather than number) based definitions. Ability to specify predefined cache clearing behaviors, specific pages to clear, or page matching selectors, from within the ProCache admin tool. New predefined cache clearing behavior: Reset cache for family of saved page (parents, siblings, children, grandchildren, and all within). New predefined cache clearing behavior: Reset cache for pages that reference saved page (via Page references). New versions of SCSS and LESS compilers. ProCache is completely ProcessWire 3.x native now (previous versions still supported PW 2.x even if 3.x was recommended). Numerous other improvements, fixes and optimizations throughout. I’ve previously mentioned a built-in crawler in ProCache. That part has been moved to a separate module called ProCacheCrawler and will be released a little later in the ProCache board. It was taking a little too much time to develop, so I didn’t want to hold up the rest of ProCache while I developed that. When installed, ProCache communicates with the crawler, identifying and adding URLs to a queue to be crawled and primed for the cache. What it does is pretty cool already, but it needs more time to develop. It’s also something that depends on being run regularly at intervals (like with CRON) so it’s a little bit of a different setup process than the rest of ProCache, which is another reason why I thought I’d develop is as a separate module. I’ll be working more on finishing development of the crawler later in the year, after the next master version of ProcessWire core is released. Next week I'll have the new ProCache version ready for download as well as a new core version on the development branch. It will focus mostly on fixes for issue reports as we continue working towards the next master version. Thanks for reading and have a great weekend!

This means that the value you are saving to the title field has had its special characters converted to HTML entities. You don't want this because the PW admin automatically applies htmlspecialchars() to the title and so the entities are being double-encoded. So if $baslik[1] is being entity encoded somewhere in your code then simply don't do this step, or if you are getting the value from somewhere where the value is already entity encoded then you can use html_entity_decode() or instruct $sanitizer->text to convert entities: $p->title = $wire->sanitizer->text($baslik[1], ['convertEntities' => true]);

See, more thanks needed :) Love your work Robin

In this part, each $addedField is already a Field object so you could simplify it to: $addedFields = $this->wire->fields->find('tags='.MODULE_NAME.''); foreach($addedFields as $addedField) { $this->wire->fields->delete($addedField); }

Mystique Module for ProcessWire CMS/CMF Github repo : https://github.com/trk/Mystique Mystique module allow you to create dynamic fields and store dynamic fields data on database by using a config file. Requirements ProcessWire 3.0 or newer PHP 7.0 or newer FieldtypeMystique InputfieldMystique Installation Install the module from the modules directory: Via Composer: composer require trk/mystique Via git clone: cd your-processwire-project-folder/ cd site/modules/ git clone https://github.com/trk/Mystique.git Module in live reaction with your Mystique config file This mean if you remove a field from your config file, field will be removed from edit screen. As you see on youtube video. Using Mystique with your module or use different configs path, autoload need to be true for modules Default configs path is site/templates/configs/, and your config file name need to start with Mystique. and need to end with .php extension. Adding custom path not supporting anymore ! // Add your custom path inside your module class`init` function, didn't tested outside public function init() { $path = __DIR__ . DIRECTORY_SEPARATOR . 'configs' . DIRECTORY_SEPARATOR; Mystique::add($path); } Mystique module will search site/modules/**/configs/Mystique.*.php and site/templates/Mystique.*.php paths for Mystique config files. All config files need to return a PHP ARRAY like examples. Usage almost same with ProcessWire Inputfield Api, only difference is set and showIf usage like on example. <?php namespace ProcessWire; /** * Resource : testing-mystique */ return [ 'title' => __('Testing Mystique'), 'fields' => [ 'text_field' => [ 'label' => __('You can use short named types'), 'description' => __('In file showIf working like example'), 'notes' => __('Also you can use $input->set() method'), 'type' => 'text', 'showIf' => [ 'another_text' => "=''" ], 'set' => [ 'showCount' => InputfieldText::showCountChars, 'maxlength' => 255 ], 'attr' => [ 'attr-foo' => 'bar', 'attr-bar' => 'foo' ] ], 'another_text' => [ 'label' => __('Another text field (default type is text)') ] ] ]; Example: site/templates/configs/Mystique.seo-fields.php <?php namespace ProcessWire; /** * Resource : seo-fields */ return [ 'title' => __('Seo fields'), 'fields' => [ 'window_title' => [ 'label' => __('Window title'), 'type' => Mystique::TEXT, // or InputfieldText 'useLanguages' => true, 'attr' => [ 'placeholder' => __('Enter a window title') ] ], 'navigation_title' => [ 'label' => __('Navigation title'), 'type' => Mystique::TEXT, // or InputfieldText 'useLanguages' => true, 'showIf' => [ 'window_title' => "!=''" ], 'attr' => [ 'placeholder' => __('Enter a navigation title') ] ], 'description' => [ 'label' => __('Description for search engines'), 'type' => Mystique::TEXTAREA, 'useLanguages' => true ], 'page_tpye' => [ 'label' => __('Type'), 'type' => Mystique::SELECT, 'options' => [ 'basic' => __('Basic page'), 'gallery' => __('Gallery'), 'blog' => __('Blog') ] ], 'show_on_nav' => [ 'label' => __('Display this page on navigation'), 'type' => Mystique::CHECKBOX ] ] ]; Searching data on Mystique field is limited. Because, Mystique saving data to database in json format. When you make search for Mystique field, operator not important. Operator will be changed with %= operator. Search example $navigationPages = pages()->find('my_mystique_field.show_on_nav=1'); $navigationPages = pages()->find('my_mystique_field.page_tpye=gallery');

Hello @ all I have 2 new methods added which take care of days with same times. It often happens that different days have exactly the same opening times. To prevent writing the same times over and over again, you can combine these days with this 2 new methods. 1) First new method to output a multidim. array print_r($page->fieldname->combinedDays()); You can use this array to create the markup by yourself. 2) Render method to output an unordered list of same opening times echo $page->fieldname->renderCombinedDays(); This method outputs a rendered string like this one: <ul class="uk-list"> <li>Mo, Fr: 08:00 - 16:00</li> <li>Tu, Th: 08:00 - 16:00, 18:00 - 20:00</li> <li>We: 16:00 - 23:05</li> <li>Sa, Su, Ho: closed</li> </ul> As you can see days with same times are combined now. Changes are added to Github now, so please download the files again if you want the latest version.? Best regards

Thank you Robin S, I find myself continually (eventually) finding the answers I am looking for with your name attached. Many thanks! Had gone round and round using the wrong method for the job I wanted. In my case, was just trying to clean up fields added by a module generated page I was playing with. Deleting api generated page, templates and fieldgroups was very easy but kept on bumping up against deleting the fields. Finally realised I could just set a tag on them, but kept using the (very wrong) getTags() method instead of the delightfully easy find('tags=...). Knew I was doing something wrong and when I eventually found your advice was acting as expected in minutes. public function ___uninstall() { parent::___uninstall(); $page = $this->pages->get('name='.self::PAGE_NAME); if ($page->id) { $page->delete(); } $addedTemplate = $this->templates->get(MODULE_NAME); if ($addedTemplate) { $this->templates->delete($addedTemplate); } $addedFieldgroup = $this->fieldgroups->get(MODULE_NAME.'-fieldgroup'); if ($addedFieldgroup) { $this->fieldgroups->delete($addedFieldgroup); } $addedFields = $this->wire->fields->find('tags='.MODULE_NAME.''); foreach($addedFields as $addedField) { $field = $this->wire->fields->get($addedField); $this->wire->fields->delete($field); }

Issue should be resolved and the file was updated on Github ?

Maybe the ProMailer can help out?

This module has no window and does not open any modal. It's still not clear to me how you are using it. I am thinking maybe you are trying to use the module in your own module? Or in the ProcessWire admin? If I could get a bit more information about this and/or a diagram/drawing (or even an animated GIF), that would help.

Hello @ all! I want to share a simple fieldtype and inputfield to store address data with you. I have created this inputfield for learning purposes and it has no fancy functionality. It is simply for storing address data such as street, number, postalcode and so on in one table. As an addition you can store latitude and longitude too, so you can use them in maps. Here is a screenshot of what it looks like: You can select which fields are mandatory and you can choose if the inputs for longitude and latitude should be displayed. These settings can be configured in the field configuration. If you find this inputfield useful you can download it at https://github.com/juergenweb/FieldtypeSimpleAddress There you will find a detailed explanation. If you have an idea of an usefull feature that can be added or you have detected a bug, please report it in my github account.

Try: // Get names of fields on the page that are tagged with "custom" $custom_field_names = $page->fields->find('tags=custom')->explode('name'); // Do something with the values of those fields foreach($custom_field_names as $custom_field_name) { echo $page->$custom_field_name; }

Page references aren't designed to contain unpublished pages. Granted, you can trick them into doing it, because the referencing page doesn't necessarily have control over the state of the page being referenced… a published page can become unpublished, among other situations. Likewise you saw that an unpublished page reference can be stored (if the input will let you select it), but unpublished pages get ignored when a field is loaded/presented. The only reason you can add unpublished pages at all is purely for the API. But now I'm wondering if that's more confusion than utility. Maybe I should just prevent unpublished pages from being stored at all--will have to think about this more. When using a PageListSelect input and you see a page with a line through it like this that means it's unpublished and you shouldn't select it. As far as I know, this is the only input that will let you select an unpublished page. It's only selectable so that you can access children, should it have any. I may be able to find a way to enforce this further, but PageList has to do a lot of things so I'm a little shy about going beyond visual indicators for this one. I'm more inclined to modify the behavior of Page references to just refuse unpublished pages completely. Thanks for your feedback--I'll experiment a bit more here.