Jump to content

charger

Members
  • Posts

    111
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by charger

  1. 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.

  2. 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.

  3. 17 hours ago, Jan Romero said:

    You could also try using a Files field instead. I imagine the page editor performance will be better and it won’t auto-generate thumbnails. Of course, you’ll have a harder time scaling and using the images in the front-end. Check this thread for more info https://processwire.com/talk/topic/26113-resize-image-manually/

     

    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.

  4. 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.

    • Like 1
  5. 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?
     

  6. 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?

    • Like 1
  7. On 1/20/2021 at 10:59 AM, charger said:

    I’m having problems getting the getQuery hook to execute. If I copy-paste the code from https://github.com/dadish/ProcessGraphQL#getquery-hook to graphql.php (or graphiql.php and ready.php for that matter) and just try to log something inside the function, the hook is never executed. @dadish is the documentation still up-to-date in this regard?

    I’m on PW 3.0.165 and module version 1.3.0

    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). 

    • Like 1
  8. The template permissions are set correctly then. The guest role has view permission on the product template.

    I’m setting the field permissions not in template context, but per field. So they all have the view permission, also in template context. Just double-checked that. What’s weird is that title and body generally work outside a repeater field. It’s only within the repeater field, that they return no values.

    Any other ideas?

  9. When trying to fetch Repeater fields with module version 1.0.5, I get responses like this one:

    [ 
    	{ 
    		"title": "", 
    		"body": "", 
    		"products": { 
    			"list": [], 
    			"__typename": "ProductPageArray" 
    		}, 
    		"__typename": "RepeaterProductGroupsPage" 
    	},
    	{ 
    		"title": "", 
    		"body": "", 
    		"products": { 
    			"list": [], 
    			"__typename": "ProductPageArray" 
    		}, 
    		"__typename": "RepeaterProductGroupsPage" 
    	} 
    ]

    So I get an answer with the expected data structure (and no errors whatsoever), but the values of the fields are always empty. Also the amount of repeater items in the response matches with the backend. This is when I send the request from the frontend (via Apollo). Looking at the same query within GraphiQL returns the data with the correct values.

    Could this be a permission problem? I correctly set the access permissions to view for all the fields mentioned in the query.

  10. My idea was to move the logic to get a unique cache name from the server to the client (by setting an ID for a query just like in the linked example) and then use that ID on the server for caching purposes. I was mainly worried that there might be a performance problem with creating hashes from complex queries, but I have no data to back that up.

  11. I implemented a very basic caching strategy for GraphQL queries with the help of PW’s native $cache methods. Here’s how my graphql.php template looks like:

    <?php namespace ProcessWire;
    
    $namespace = 'graphql';
    $serializedQuery = file_get_contents('php://input');
    $cacheName = hash('md5', $serializedQuery);
    
    $cacheData = $cache->getFor($namespace, $cacheName);
    
    if (!$cacheData) {
      $cacheData = $modules->get('ProcessGraphQL')->executeGraphQL();
      $cacheSaved = $cache->saveFor($namespace, $cacheName, $cacheData, $expire = 604800);
      $log->save('graphql', "cache saved $cacheSaved with name $cacheName");
    }
    
    echo json_encode($cacheData, true);

    When saving a page in the backend, for now I just clear the whole cache associated with this namespace (inside ready.php )

    <?php namespace ProcessWire;
    
    $pages->addHookAfter('saveReady', function($event) {
      $deleted = wire('cache')->deleteFor('graphql');
      if ($deleted) wire('log')->save('graphql', 'cache deleted');
    });

    Serializing the whole query just to get a unique cache name obviously isn’t optimal. How about if the module supported globally unique IDs that could then be used as cache name instead?

    • Like 1
×
×
  • Create New...