kixe

@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