kixe

@lpa I opened an issue which is related. https://github.com/processwire/processwire-issues/issues/1987

@DV-JF Fixed.

I came across this problem and solved it with a hook. In my case, I use the image field in 2 different repeaters and needed a dependency on the template. Field names of custom image fields always contain the ID of the page or repeater page to which the image field is assigned. e.g. "image_caption_image_repeater18596_9cc494cc88e6dc55046f042aa5b3492d" whereas 18596 is the page / repeater page id wire()->addHookAfter('InputfieldWrapper::renderInputfield', function($e) { $inputfield = $e->arguments[0]; if (strpos($inputfield->name, 'image_caption_image_repeater') === 0) { $pid = (int) strstr(substr($inputfield->name, strlen('image_caption_image_repeater')), '_', true); $tn = wire('pages')->get($pid)->template->name; if ($tn == "repeater_cards") $e->return = ''; } });

Loading a website after updating to PHP 8.x failed. The connection to the server was reset while the page was being loaded. NS_ERROR_NET_RESET PHP error was not catched, nothing displayed, nothing logged. After a long search, it turned out that the Gettext extension was responsible for the fatal error. Code example to reproduce: $locale = 'de_DE'; setlocale(LC_ALL, $locale); echo gettext("foo bar"); // NS_ERROR_NET_RESET After adding the environment variable LANG it worked as expected. $locale = 'de_DE'; setlocale(LC_ALL, $locale); putenv("LANG=$locale"); echo gettext("foo bar"); // foo bar Same behaviour with ngettext() and maybe other Gettext functions. Alternatively, the problem could also be solved with putenv("LC_ALL=$locale"); Possibly affected: ProcessWire\Languages::setLocale() I found little information about this behavior on the Internet.

@eelkenet Done. Try Version 1.1.8.

Done ...

FieldtypeColor always stores the value as 32-bit (int) in the database (page field). If we are talking about InputfieldColor, the transmitted value is either a 24- or 32-bit colour hexcode, which depends on the selected inputType as described above. I assume you want to use the input field as a configuration field for your module. In this case, the transmitted value of the input field is relevant. Module configuration data is always stored as a json encoded string in the database.

BTW. Your solution will not work ... $color_in = "#ffff0000"; // red with alpha channel $color_out = '#' . ltrim( $color_in, '#ff'); var_dump($color_out); // "#0000" invalid color hex code $color_out = '#' . substr($color_in, 3); var_dump($color_out); // "#ff0000" your expected result

$f = wire('modules')->get('InputfieldColor'); $f->inputType = 1; Simplest solution: Choose inputType 0 or 1. If you want to use the Spectrum color picker (inputType = 3). I added an option to explicitly disable the alpha channel. Please update to version 1.1.6 and disable the alpha channel: $f = wire('modules')->get('InputfieldColor'); $f->inputType = 3; // spectrum $f->alpha = false; If you want to use a custom JS input type (inputType = 4), the alpha channel is disabled by default. The following additional properties are provided to make it work with your custom color picker: initJS (initial JS) fileJS (custom JS file) fileCSS (custom CSS file) $f = wire('modules')->get('InputfieldColor'); $f->inputType = 4; // custom js and css $f->initJS = '$("{id}").initCustomJS({ color: "{value}" });'; // placeholders for value and id of HTML input element $f->fileJS = "/path/to/file.js"; $f->fileCSS = "/path/to/file.css";

@gornycreative Go to Field settings > 'Details' tab and choose your preferred output formatting.

It's public now.

Hi @HMCB Currently it is not so easy to provide an default value option for number fieldtypes other than Integer, because all core number Inputfieldtypes using the same rendering function: InputfieldInteger::render(), converting any init or default value to int. So currently there is no option to define default values with decimal places. The core InputfieldFloat and / or InputfieldInteger needs an update to allow default values with decimals. In a second step number fieldtypes could include an option to define a default value. I wrote a Module as a workaround until the core issues are fixed. https://github.com/kixe/FieldtypeDecimalPlusDefault

or simply $config->debug = false; $config->moduleInstall('download', true);

You implemented code from another author under another Namespace (Version 1.32 of parseUserAgentString.php). Current Version is 1.36 Any updates planned? https://github.com/trparky/User-Agent-Parser/blob/main/parseUserAgentString.php As common practice in the ProcessWire community, it would be great if you could enable issues in the associated GitHub repo. Furthermore it would be nice if the module author felt responsible for parts of the code that he has copied from other sources. https://github.com/techcnet/ProcessPageViewStat/pull/1

@Jozsef I have a lot of understanding for your problem, but it definitely has nothing to do with this thread (CronjobDatabaseBackup support). The error message you see is generated by a core class and is a result of the configuration of the server you are using. I recommend looking for a related thread or starting a new thread on this topic.

Increase your PHP maximum execution time: https://www.simplified.guide/php/increase-max-execution-time

Added some useful functions to FieldtypeColor class: /** * Find the "naive" difference between two colors. * @param int[] $color_a Three-element array with R,G,B color values 0-255. * @param int[] $color_b Three-element array with R,G,B color values 0-255. * @return int */ public function getColorDistance(array $color_a, array $color_b) /** * Find the difference between two colors' luminance values. * @param int[] $color_a Three-element array with R,G,B color values 0-255. * @param int[] $color_b Three-element array with R,G,B color values 0-255. * @return int */ public function getLuminanceDistance(array $color_a, array $color_b) /** * Find the closest named color * @param hexcolor 6 or 8 digits, with or without leading '#' * @return string */ public function getClosestColorName(string $color) Usage example: $fc = $modules->get('FieldtypeColor'); $colorname = $fc->getClosestColorName('#01fb99'); var_dump($colorname); // string(17) "MediumSpringGreen" I needed this for the COLOR property in .ics file type. According to the specifications, the value must be a valid CSS3 color name. https://icalendar.org/New-Properties-for-iCalendar-RFC-7986/5-9-color-property.html

https://github.com/kixe/FieldtypePageContextData/issues

@MrSnoozles Edit 1: Thanks for feedback. I fixed it in the recommended way. Edit 2: It's good that you found a solution to your needs.

I've pushed a fix. The separator must be translated into a real line break (expected by the Inputfield). I changed the translation to "\r\n" instead of "\n" only, which should work cross platform. Continue to use the string '\n' in the field settings. Please update to version 1.0.1. Could you please give feedback if it works? The pipe '|' you mentioned is already reserved to separate an option 'value' from the option 'title' (@see SelectableOptionManager). I prefer to handle the setup according (very close) to the expectations of the inputfield. ProcessUser and possibly some other processes for editing system pages are not supported. In the special case of ProcessUser, the GET-Parameters forfield and forpage are removed from the url of the modal window for whatever reason. Any idea? The module is still in an alpha stadium. Thanks for testing and feedback.

Make child pages of page beeing edited selectable in a page field named: nameOfTheField $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->hasField == 'nameOfTheField') { $event->return = $event->pages->find('parent=' . wire('input')->get->id); } });

I made this post yesterday:

Field that stores one or more references to ProcessWire pages with additional data in field context. Values are editable via page edit modal of the referenced page provided from the field if module AdminPageFieldEditLinks is installed and "Enable link to create new pages?" is checked in field settings. Requirements: AdminPageFieldEditLinks >= 3.1.4 https://github.com/kixe/FieldtypePageContextData https://processwire.com/modules/fieldtype-page-context-data/ Use case example: The planning of the Tonmeistertagung in the CCD (Congress Center Düsseldorf) from November 3rd, 2021 to November 6th, 2021 is in the finalization phase. The conference consists of a conference part and an exhibition. The planning is done via a separate frontendless PW instance. There, all companies (pages) that are active at various events are kept in a pool. Changes (address, logo) can always be done there. For the exhibition of the current conference in November, the exhibitor-companies (pages) are selected via a page reference field. A stand number must now be assigned to each selected company (page). We had originally solved this using the Profield FieldtypeTable. However, this had the disadvantage that each entry again made all companies available for selection and did not recognize which were already selected in a previous table row. The new field type now allows the value (company's stand number) to be assigned to a Company (page) in context to a specific Pagefield living in a specific page. https://tonmeistertagung.com/en/exhibitors/exhibition/

I don't know how well you know the PW API but it's easy to hook in Pages::delete() and Pages::save() In your sattelite instances you just need a name for each user, nothing else. Manage the users in your main instance only and update users via PW API in the others. What is your special usecase? Why do you have multiple PW Installs for the same users?

If a user is succesfully loggedin in another instance you can force login in the current (only if the user name matches) – no password required. Checkout the code I posted: and add this: $xy->users->setCurrentUser($_user); // search for this wire('session')->forceLogin($_user->name); // add this I would assign profile-edit permission only in the main instance. All this needs a bit coding experience. Be careful and don't create security holes!