charger
Members-
Posts
111 -
Joined
-
Last visited
-
Days Won
1
charger last won the day on August 25 2021
charger had the most liked content!
Profile Information
-
Gender
Not Telling
-
Location
Switzerland
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
charger's Achievements
Sr. Member (5/6)
37
Reputation
-
InputfieldFloatRange - A range slider InputField
charger replied to eelkenet's topic in Modules/Plugins
@eelkenet perfect, works great. Thanks a lot! -
InputfieldFloatRange - A range slider InputField
charger replied to eelkenet's topic in Modules/Plugins
Would be cool if the field allows for a default value (next to min and max), so e.g. when min is 0 and max is 1, it currently defaults to 0.5, but I would sometimes prefer the default to be 0. @eelkenet would this be complicated to implement? -
Not sure if this helps anything, but I also had localUrl() problems (same error as with SEO module above) in my helper classes that prepare the output for the API and could solve it by manually redeclare the hook as described here: When deactivating the URL hook in the module settings, it works flawlessly without the adjustments above.
-
When creating image variations, is there a way to suppress the creation of the variations in the original image format and only create the webp format? I can currently see (in PW 3.0.210) that a call to $image->width($width)->webp first creates a variation in the original file format. Is this a necessity? I only really need the webp variations, and creating unnecessary variations is time-consuming and takes up disk space.
-
[SOLVED] How to manage image field with hundreds of images?
charger replied to charger's topic in General Support
That did the trick! The Files field is indeed a lot more performant than the Images field. On top of that, I noticed it doesn’t seem to alter the original image file during upload. When I was using the Images field, it seemed to corrupt the EXIF/IPTC data of the original image file. I could only read that information of about 50% images after the upload. Using the Files field, I can read that data from all the images. -
I have a single page with an image field that hold ~600 images. Now apart from it being not very handy to handle, it also takes A LOT of time to load (had to increase PHP timeout to 120s) and it only displays roughly a third of the images in the backend (although I can see all 600 image files in the corresponding assets/files/ folder). There are also no errors in the console. I read in another forum post a comment from Ryan that image fields don’t scale infinitely, but no explanation to why that happens. Does anyone have experiences with such an amount of images or alternative solutions to the problem? Just to be clear: This is not about rendering the images on the frontend, but about adding them to an image field. I’m on localhost with MAMP and PHP performance settings bumped. I’m using PW 3.0.200 and PHP 7.3.3.
-
charger started following PAGEGRID – Page Builder Preview
-
When using single quotes \n is not interpreted as newline character. Btw. GitHub issue was created.
-
That I noticed too. But in my case I have to use double quotes as I also use variables within the string. Tried every combination I could think of ?
-
OK, will try to use variables then to insert the newline character. But it’s definitely in the docs. See the attached screenshot.
-
I’m on PW 3.0.184 and PHP 7.3.3 and have an issue when I insert a \n into a translation string. The string shows up correctly in the language translator in the backend. However, if I translate the string and then echo it via template file, it won’t return the translated string but its default value. As soon as I remove the \n out of the translation string, the translated value is correctly returned. I used the example from the docs to test: $out = __("It's time for you \nto get to the party."); // good Can someone confirm this?
-
Language alternate field with value 0 not respected
charger replied to charger's topic in Multi-Language Support
So the culprit is here: https://github.com/processwire/processwire/blob/master/wire/modules/LanguageSupport/LanguageSupportFields.module#L159 Using empty() to check for a value in the field will return true if that value is 0. I changed it to !isset() and now it is working as expected. Posted here: https://github.com/processwire/processwire-issues/issues/1431 -
Language alternate field with value 0 not respected
charger replied to charger's topic in Multi-Language Support
Can someone reproduce this behavior to check if this is a bug? -
Language alternate field with value 0 not respected
charger posted a topic in Multi-Language Support
I have the two integer fields called price and price_de. When I request the value of price with language de, it only provides the correct value if price_de is any other than empty or greater than 0. While I would expect an empty field to fall back to the value of the default language, having a value 0 should actually return 0. I set the option Blank and 0 have different meanings in both fields. I’m currently running PW 3.0.165. Anyone else experiencing this? -
Here’s the updated code that works for me: <?php namespace ProcessWire; use GraphQL\Type\Definition\Type; $processGraphQL = $modules->get('ProcessGraphQL'); wire()->addHookAfter('ProcessGraphQL::getQueryFields', function ($event) { $query = $event->return; $query[] = [ 'name' => 'hello', 'type' => Type::string(), 'resolve' => function () { return 'world!'; } ]; $event->return = $query; }); echo $processGraphQL->executeGraphQL(); The hook name changed from getQuery to getQueryFields. Also, the new field is now just pushed to the array instead of using the addField() function (from the previous library).