theoretic

Hello everybody! And thanks for Processwire! It appears that i have an interesting case concerning page fields resaving via modules. Let's suppose we're making a module which should run every time when a page is saved. Our module should calculate a value based on the values of some page fields, place this value to a dedicated field (in my case it's called 'mark') and save the page again. Below is the example of possible module code: public function init() { $this->pages->addHookAfter('save', $this, 'hookCalculateMarks'); } private function calculateMarks($page) { $page->of(false); //doing some calculations... //$page->save(); //will trigger endless loop calling hookCalculateMarks again and again! $page->of(true); $this->message("Marks calculated."); $this->calculated = true; } public function hookCalculateMarks($event) { $page = $event->arguments[0]; $this->calculateMarks($page); } The problem is that the commented page->save() triggers a save event which triggers the hookCalculateMarks which triggers page->save() which triggers the hookCalculateMarks which... oops, my mysql server has gone away. Tried to use a variable like $calculated... var $calculated = false; //some code skipped private function calculateMarks($page) { $page->of(false); //$page->save(); //will trigger endless loop calling hookCalculateMarks again and again! $page->of(true); $this->message("Marks calculated."); $this->calculated = true; } public function hookCalculateMarks($event) { $page = $event->arguments[0]; if( $this->calculated ) return; $this->calculateMarks($page); } ...but the problem is still present. Endless loop again. So what are the best practices for this case? What is the safe way to (re)save a field value afgter a page is saved? Thanks in advance!

Hi everybody! It appears that there's a problem with the new version of General Settings 1.2.2 and PW 3.0.102 (without Lister Pro). Tried to install the General Settings 1.2.2 onto a fresh PW 3.0.102 via ModuleClassName, got an error of kind "GeneralSettings module is required". Also tried to download and install the General Settings 1.2.2 manually. Now the installation zip archive holds two modules: GeneralSettings.module and ProcessGeneralSettings.module . Tried to install GeneralSettings.module first, it was okay, but it appears that this module configuration has no effect. Tried to use $g_settings->my_setting_name in templates, no effect, $g_settings is NULL. Another glitch: there's no possibility to edit the settings via GUI at General Settings configuration page, could only trash/untrash and reorder them. The only way of adding/editing the settings is to edit the JSON on the same page. Finally went back to older ProcessGeneralSettings 1.1.4 which works like a charm. Thanks in advance for the possible debug and corrections!

Hi there! And thanks for Processwire! Maybe i'm not very attentive but couldn't find any tutorial on creating custom fieldtype with custom inputfield. Would like to make one for selecting color(s) from predefined list of colors. The closest existing match is FieldtypeSelectOptions with InputfieldSelect but i need something different. There's a very good post from @Soma which is, however, insufficient to begin building my own fieldtype or at least to attach the existing inputfield to an existing field. Will appreciate any help. Thanks in advance!

@Soma, great example, thanks! However it's not very clear how to assign this (or similarly developped) custom inputfield to existing data field. Thanks for possible clarifications!

@Robin S, bravo! Cannot test it now (moved to a simper solution) but for sure Your proposal should work. The only thing i needed was to get the page holding both repeaters, and You did it using $page = $page->getForPage();

@Robin S, thanks! Tried this, but still no result, the select options are empty howerver $page->variants is nonempty. P.S. Found a simpler solution which works without necessity of getting one repeater from another. The question however remains unresolved.

Hello there! And thanks for Processwire. Got one more interesting question. One of my templates called goods has two repeaters. The first one is variants, each item containing possible sizes, colors and so on. The second one is available_variants, each item should contain a region and a variant which should be selectable from the list of variants. So the task is to get items of one repeater from inside the page reference field which is the part of another repeater, both repeater belonging to the same page. Processwire gives some options for retrieving selectable pages in this case. We can use: Parent. Not an option because we need dynamic parent being in fact the current page which contains both repeaters. Template. Not an option again because we need to select repeater items not only by template but also by page id which is dynamic. Custom find. Could be a solution but have no idea how to substitute the current page id into ID query. Selector string. It's almost what we need, but again i have no idea how to substitute something like "parent={$parent->id}" in this case. Custom PHP code. This needs to be placed inside site/ready.php and should contain a hook which finds pages using all the power of PW API. Think that the last option is the solution, but could not get the result i need. The simplest possible way seems to use $event->arguments('page')->variants. But it returns nothing. Tried different selectors like "template=repeater_variants, parent=".$event->arguments('page')->id , but still no result. Will be grateful for any help. Thanks in advance!

Hi there! And thanks for Processwire! This is rather a question than a feature request, maybe there's a well known solution which i missed. So what about aggregation in selectors? Let's suppose we have a PW-powered shop where any product has a rating made by customers. Every time the user polls two data fields are updated: points and votes. The rating is calculated as this: $rating = $page->points / $page->votes; It was easy, yeah. But what about sorting products by their rating? Basically there are two ways of doing it: Creating one more field called rating and updating it after every vote. For sure it will work, but we have to create an extra data field which in fact stores data based on two another fields. Bad practice i think. Getting all products into array and applying a cutom sort function. Will work again, but this demands much more coding than using the native PW selectors. But how could it be done in the best possible way? Let's imagine this: $products = $page->children("sort=points/votes"); Or maybe this: function rating($a,$b){ return $a->points/$a->votes > $b->points/$b->votes; } $products = $page->children("sort=rating()"); Okay, let's go even deeper. Maybe we need "virtual" fields which are not stored in DB tables like other PW fields but represent the dynamically calculated values? $page->rating = function(){ return $page->points/$page->votes; } $products = $page->children("sort=rating"); Will be glad to see advice on the best practices. Thanks in advance!

@BitPoet, thanks! It just works. But the syntax is far from being obvious. Maybe it could b a good idea to include "field1=val1|field2=val2" syntax in further PW releases. As far as i see it will not create conflicts with the existing selector syntax.

Hello there! And thanks for Processwire! It may appear a noob question but what about selectors like "field1=val1||field2=val2"? I mean that the page we're looking for should have field1=val1 OR field2=val2 . There's plenty of examples for cases like "field=val1|val2" but it's another case. Practical example: frontpage uder registration. User should enter nick and email, and both of them should be unused by other registered users. It's logical to use something like $userTest = $users->get("nick={$input->post->nick}|email={$input->post->email}"); But this doesn't work. That's the best practice in this case? Thanks in advance!

@bernhard , @SamC , it's great what You're planning to do, but maybe it could be better just to provide some different compiled css files inside AdminThemeUIKit and to give users a possibility to switch between them?

@bernhard sorry, i though You mean the design approach not the technical realization. I just did some auto-replacements in /wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/css/uikit.pw.min.css . The better way will be to do the same with /wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/css/uikit.pw.css and then to minimize it using Your preferred tool.

@bernhard , thank You ! It's nice to see that i can do something useful for the community. I clearly understand that anyone can have his own preferred colors, but the convenience and positive UX can be achieved if we will accept some simple design rules. Consistency. Any color, any font variation should have the same meaning across the whole app. E.g. every link should be blue, every visited link should be grey and so on. The current AdminThemeUIKit has no major drawback of this kind. The link and button colors should mean what they mean in common. The blues and greens are the metaphor of something positive, greys are neutral, light greys are about something disabled and/or inaccessible. As for reds -- they're commonly threated as a sign of risk and a metaphor for dangerous actions. Here lies one of the important drawbacks of current AdminThemeUIKit . Every link is red -- why? The "positive" buttons like "Add new something" become red when hovered -- what is the reason? Okay, we humans are able to quickly adaptate to almost everything. But adaptation always means discomfort and perplexion. High contrasts and bright colors are for wow effect only. Admin interfaces need the light, moderate-contrast and calm appearance. The current color scheme of AdminThemeUIKit has the major drawback of high contrast and bright colors. Details are below. The bigger area we fill with color the less bright and less saturated this color should be. Just imagine the AdminThemeUIKit's header totally filled with red: it will be extremely annoying. The current almost-black header fill is also far from being ideal. Too dark, too saturated, too much contrast with the rest of the page. This big area needs a light, low-brightness, low-saturation filling. On the other hand, the textual links deserve the bright and highly saturated colors (but not reds please, at least for "positive" links). Hope this will help. And thanks again for a perfect product!

Thanks Adrian! Works like a charm. Maybe this deserves to be added to docs.

Hi there! And thanks for Processwire. Got an interesting question: is it possible to programmatically get the default value of SelectOptions field? Getting all possible values is not a problem, but docs can say nothing about getting the default value. Thanks in advance!

Since no one tried to revive the "oldish" UIKit theme -- i did it. Moderate contrast Non-aggressive color scheme Light colors, no dark backgrounds Very close to the original UIKit design Feel free to replace the /wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/css/uikit.pw.min.css with the file i upload here. Hope it will be useful for community.uikit.pw.min.css uikit.pw.min.css

Hi there! And thanks for Processwire! Just upgraded one of my PW sites to the new core-integrated UIKit admin theme and feel a bit confused. The "old" UIkit theme was in white and blue colors, rather minimalistic and very convenient for intense work. The current color scheme is less convenient: darker colors, rough contrasts. Okay, it's just my personal opinion -- but having possibility to choose different color schemes could be a good idea for this perfect admin theme. In plus, there's no need to build the "white-blue" theme from scratch -- it was already a part of UIkit admin theme recently. Thanks in advance!

@netcarver, thanks! Works now.

@Macrura, think that wire(‘settings’) doesn't work, at least if we deal with PW 3.x and ProcessGeneralSettings. Your approach gives the error: Error: Function name must be a string

@adrian, thanks for that! Didn't know about that module. I'm rather impressed by @Macrura 's work, but currently it's a bit overkill for me. The only thing i needed beyond the standard ProcessGeneralSettings functionality was the ability to save the changed settings. By the way, is there a possibility to access $settings from inside functions, modules etc?

Hi there! And thanks for Processwire! Would like to propose an extension of this module. Sometimes it could be very convenient to update settings dynamically and then to save them. A practical example: currency rates for a multi-currency shop. It's logical to store rates as general settings. But it's also logical to make a script which gets the actual rates from external website and then re-saves them. Some mockup code: $currencies = ['AUD','GBP']; $currencyRates = []; //getting currency rates skipped foreach( $currencies as $currency ) $settings->$currency = $currencyRates[$currency]; $settings->save(); Unfortunately there's no save() method in the original ProcessGeneralSettings.module , so i had to write it: public function save() { $old = $this->data; $data = json_decode($old['settings'], true); $new = array(); foreach ($data as $key => $field) { $new[$key] = $field; $new[$key]['value'] = $old[$field['api']]; } $old['settings'] = json_encode($new); wire('modules')->saveModuleConfigData($this, $old); return $this->data; } Have tested it, works like a charm. Would like to merge it into the official module.

Hi there! And thanks for Processwire! Another bug found for fields of type FieldtypePage. There's a "custom find" section in the "input" tab allowing to select several conditions for finding pages which will be included into thepages listing. This feature doesn't find any page. Tried to use "template" and "id" conditions, always no result. Fortunately, the "template + additional templates" section works fine. My PW is 3.0.77. Hope that helps, and thanks in advance!

@fbg13, thanks a lot! Worked like a charm.

Hi there! And thanks for Processwire which i like very much. Got a problem while trying to update from 3.0.65 (with admin theme UIkit ) to 3.0.78 . Tried to do it both via ProcessWireUpgrade module and by copying/replacing the files and dirs manually. In every case i got the problem with UIKit admin theme. The first try to reload any admin page after update gives the following errors: Notice: Undefined variable: adminTheme in D:\work\sites\home\sea.dev\webroot\site\modules\AdminThemeUikit\init.php on line 121 Fatal error: Call to a member function get() on null in D:\work\sites\home\sea.dev\webroot\site\modules\AdminThemeUikit\init.php on line 121 It is officially recommended to reload the page several times after update to get the admin interface functional again, but it's not my case. The problem still persists. It's obvious that $adminTheme is not initialized. Reverting back to /wire dir of version 3.0.65 removes the problem. Switching to default admin theme and then updating to 3.0.78 makes the admin interface fully functional -- but switching to UIKit admin theme leads to the error again. Will appreciate any help. Thanks in advance!

Hi everyone! And thanks again for a perfect product. It appears there's a small bug in the implementation of fieldset. If we rename a field of type FieldsetTabOpen, the auto-created field of type FieldsetTabClose won't auto-rename. E.g. if we create a fieldset called "noises", two fields will be created -- "noise" (type: FieldsetTabOpen) and "noise_END" (type: FieldsetTabClose). And when we later rename the field "noise" to "acoustics", the field "noise_END" still keeps its name. The auto-generated field description will also remain unchanged. This is only a minor bug, but removing it could make the Processwire even better. Thanks in advance!