Jump to content
horst

Croppable Image 3

Recommended Posts

@tpr: I added the tiny thumbs.

One little downside is, when returning back from the Modal, after creating the new Cropimage, they are not updated automatically. Only after page refresh.

screen_20170902_182100.png.8b90e9572223c0b11dd2779e4f34ff71.png

  • Like 2

Share this post


Link to post
Share on other sites

Thank you @horst for the new tiny thumbnail. It's very useful for repeaters where the hover isn't working on them.

When I crop my predefined crop "thumbnail" it doesn't remove it's variations:

test.360x0n-thumbnail.jpg
test.480x0n-thumbnail.jpg
test.660x0n-thumbnail.jpg

Isn't the removal of CropImage children suppose to remove the above 3 variations so when the frontend page is re-visited those variations will be auto generated again with the new crop version?

Share this post


Link to post
Share on other sites

@PWaddict

My variations looks like imagename.-work-thumb.160x135.jpg, where 160x135 is added by me from api (markupsrcset module). It seems you have a different naming somehow.

@horst

You got a new PR - button preview update on new crop + prevent PW lightbox on preview img click (lightbox showed 'Error load image') + style updates

Feel free to remove the new preview button styles if you don't like it.

ci3-preview-btn.png.2d4f54c050bee8e5c3907c769b9fa21d.png

  • Like 1

Share this post


Link to post
Share on other sites

@horst I think that I found why the variations aren't removing. Their syntax is different.

Variations
test.-thumbnail.jpg (Predefined Crop)
test.-thumbnail.0x48n.jpg (New tiny thumbnail)
test.360x0n-thumbnail.jpg
test.480x0n-thumbnail.jpg
test.660x0n-thumbnail.jpg

As you can see the 360, 480 & 660 variations that I want to get removed have different syntax.

Share this post


Link to post
Share on other sites

@tpr Here is how I'm cropping them:

$thumb_medium = $photo->photos_main_photo->getCrop("thumbnail", "width=660");
$thumb_small = $photo->photos_main_photo->getCrop("thumbnail", "width=480");
$thumb_x_small = $photo->photos_main_photo->getCrop("thumbnail", "width=360");

I do not use the markupsrcset module. Is there something I could do to change the syntax or it has to be changed from the CI3 module side?

Share this post


Link to post
Share on other sites

I just use this syntax:

$page->images->first()->getCrop('portrait');

I guess horst needs to fix the removal for the other syntax as well.

Share this post


Link to post
Share on other sites

@horst @tpr The button preview never update on a production server. On localhost it's working properly.

The cropping is broken on a production server. The area I choose to crop is always different on the Accept/Redo Crop screen. On localhost it's working properly.

I'm using the version 1.1.10 on both localhost and the server.

Share this post


Link to post
Share on other sites
11 hours ago, PWaddict said:

@tpr Here is how I'm cropping them:


$thumb_medium = $photo->photos_main_photo->getCrop("thumbnail", "width=660");
$thumb_small = $photo->photos_main_photo->getCrop("thumbnail", "width=480");
$thumb_x_small = $photo->photos_main_photo->getCrop("thumbnail", "width=360");

I do not use the markupsrcset module. Is there something I could do to change the syntax or it has to be changed from the CI3 module side?

 

11 hours ago, tpr said:

I just use this syntax:

$page->images->first()->getCrop('portrait');

I guess horst needs to fix the removal for the other syntax as well.

 

Huh! This is interesting! :o

I need to explain a bit about the naming conventions of image filenames in PW, I think.

/site/assets/files/{page-id}/basename.jpg
/site/assets/files/{page-id}/basename.0x260.jpg

/site/assets/files/{page-id}/basename.-tag1-tag2.jpg
/site/assets/files/{page-id}/basename.-tag1-tag2.200x300.jpg

/site/assets/files/{page-id}/basename.800x800.-tag5-tag3.jpg
/site/assets/files/{page-id}/basename.800x800.-tag5-tag3.200x300.jpg

Beginning after the basename, with the first dot, every dot indicates an imagevariation that also exists as a file. (only the last dot leads to the file-extension)

Every previous part in the chain is the [source | parent | original] of the actual part.

The tags chain, implemented into PW around 2.5 and made to become very robust and foolproofed by Ryan around 2.6, was meant to be used as lowercase tags, concatenated by - chars. This very restrictive usage is due the valid filename characters (lowercase), and the preserverd dot, and to prevent concatenating multiple same tagnames. (this is cleaned up to become unique in the filenames).

But this is not very userfriendly in cases like the CropNames, and the users are not aware of this restrictions why it is / would be important to follow them.

Thats why I have to handle the cropnames less restrictive. Thats also the reason why the implemented tag system in PWs imagenames cannot be used like intended. All the cool methods to get the variations of a parentimage (getVariations(), isVariation()) will fail in many cases when using images with an (invalid) tagname / cropname!

That's why I was happy to find another bulletproof solution for getting rid of the srcset variations. (Detecting the children of a crop-parent)

 

@PWaddict The way you uses it isn't an intended one. You create different INTERMEDIATE crops. The intended way is to create 1 INTERMEDIATE crop image, that serves as parent for the derived variations. But this intermediate functionality also is obsolete and will become deprecated in the next version, as it isn't much useful but leads to code bloat and confusion.

Also it sin't possible to detect derivatives of that sort. Imagine a setup with 3 cropnames: test & test-portrait & test-landscape.
As we have already read above, people do this a lot, using invalid cropnames / tagnames, with - chars or Camelcase, etc.
Now go select and create a new crop of the "test" cropname. It will errorinously also delete all variations of test-portrait and test-landscape. Also image variations that may have the cropname on another place in the filename will get deleted too.
The only way to detect variations is to keep the parent-children relation. (Blood is thicker then water, :) )

Maybe you can use it this way:

$thumb_master = $photo->photos_main_photo->getCrop("thumbnail");
$thumb_medium = $thumb_master->width(660);
$thumb_small = $thumb_master->width(480);
$thumb_x_small = $thumb_master->width(360);

This is the intended way that brings you back into sync with the system.

  • Like 3

Share this post


Link to post
Share on other sites
13 minutes ago, horst said:

 

 

Huh! This is interesting! :o

I need to explain a bit about the naming conventions of image filenames in PW, I think.


/site/assets/files/{page-id}/basename.jpg
/site/assets/files/{page-id}/basename.0x260.jpg

/site/assets/files/{page-id}/basename.-tag1-tag2.jpg
/site/assets/files/{page-id}/basename.-tag1-tag2.200x300.jpg

/site/assets/files/{page-id}/basename.800x800.-tag5-tag3.jpg
/site/assets/files/{page-id}/basename.800x800.-tag5-tag3.200x300.jpg

Beginning after the basename, with the first dot, every dot indicates an imagevariation that also exists as a file. (only the last dot leads to the file-extension)

Every previous part in the chain is the [source | parent | original] of the actual part.

The tags chain, implemented into PW around 2.5 and made to become very robust and foolproofed by Ryan around 2.6, was meant to be used as lowercase tags, concatenated by - chars. This very restrictive usage is due the valid filename characters (lowercase), and the preserverd dot, and to prevent concatenating multiple same tagnames. (this is cleaned up to become unique in the filenames).

But this is not very userfriendly in cases like the CropNames, and the users are not aware of this restrictions why it is / would be important to follow them.

Thats why I have to handle the cropnames less restrictive. Thats also the reason why the implemented tag system in PWs imagenames cannot be used like intended. All the cool methods to get the variations of a parentimage (getVariations(), isVariation()) will fail in many cases when using images with an (invalid) tagname / cropname!

That's why I was happy to find another bulletproof solution for getting rid of the srcset variations. (Detecting the children of a crop-parent)

 

@PWaddict The way you uses it isn't an intended one. You create different INTERMEDIATE crops. The intended way is to create 1 INTERMEDIATE crop image, that serves as parent for the derived variations. But this intermediate functionality also is obsolete and will become deprecated in the next version, as it isn't much useful but leads to code bloat and confusion.

Also it sin't possible to detect derivatives of that sort. Imagine a setup with 3 cropnames: test & test-portrait & test-landscape.
As we have already read above, people do this a lot, using invalid cropnames / tagnames, with - chars or Camelcase, etc.
Now go select and create a new crop of the "test" cropname. It will errorinously also delete all variations of test-portrait and test-landscape. Also image variations that may have the cropname on another place in the filename will get deleted too.
The only way to detect variations is to keep the parent-children relation. (Blood is thicker then water, :) )

Maybe you can use it this way:


$thumb_master = $photo->photos_main_photo->getCrop("thumbnail");
$thumb_medium = $thumb_master->width(660);
$thumb_small = $thumb_master->width(480);
$thumb_x_small = $thumb_master->width(360);

This is the intended way that brings you back into sync with the system.

Thank you for providing this important information regarding PW image filename conventions and a very good explanation of the reason why they exist.  It cleared things up for me, at least.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, PWaddict said:

@horst @tpr The button preview never update on a production server. On localhost it's working properly.

The cropping is broken on a production server. The area I choose to crop is always different on the Accept/Redo Crop screen. On localhost it's working properly.

I'm using the version 1.1.10 on both localhost and the server.

@horst I switched back to 1.1.7 and I still have the cropping problem on the server. It doesn't crop exactly the area I choose. I don't understand how is this possible to happen???? On another site on the same server with the same 1.1.7 version it crops properly.

Share this post


Link to post
Share on other sites
1 hour ago, PWaddict said:

@horst I switched back to 1.1.7 and I still have the cropping problem on the server. It doesn't crop exactly the area I choose. I don't understand how is this possible to happen???? On another site on the same server with the same 1.1.7 version it crops properly.

@horst It was the filename of the image that causing the problem. The filename was _MG_6550_copy.jpg and I changed it to test.jpg and now I can crop it properly. The button preview works too :) 

The _MG_6550_copy.jpg when uploaded it gets auto renamed to mg_6550_copy.jpg and it works fine on locahost but I don't understand why it doesn't work with that filename on the server too.  What's wrong about mg_6550_copy.jpg ?????

Share this post


Link to post
Share on other sites
26 minutes ago, PWaddict said:

The _MG_6550_copy.jpg when uploaded it gets auto renamed to mg_6550_copy.jpg and it works fine on locahost but I don't understand why it doesn't work with that filename on the server too.  What's wrong about mg_6550_copy.jpg ?????

You are local on Windows? Windows filesystem isn't case sensitive. Others are. That's why it works on windows, and that's why windows is not the best dev-platform.
So, I'm working on windows too, but have the advantage that I'm working with win-computers since back to times of DOS. (That was before Windows 3.1 :) ) Some of the restrictions from that times I'm using until today, regardless of current working platform:

  • only lowercase filenames, if there is a 1% change that a file may uploaded to webspace,
  • no spaces in filenames, - never! (Is of interest until today, if you use CLI progs somehow.)
  • ... but I'm very happy that the filename length is more than 8.3 today :lol:

 

Share this post


Link to post
Share on other sites
1 hour ago, horst said:

You are local on Windows? Windows filesystem isn't case sensitive. Others are. That's why it works on windows, and that's why windows is not the best dev-platform.
So, I'm working on windows too, but have the advantage that I'm working with win-computers since back to times of DOS. (That was before Windows 3.1 :) ) Some of the restrictions from that times I'm using until today, regardless of current working platform:

  • only lowercase filenames, if there is a 1% change that a file may uploaded to webspace,
  • no spaces in filenames, - never! (Is of interest until today, if you use CLI progs somehow.)
  • ... but I'm very happy that the filename length is more than 8.3 today :lol:

 

It might be a cache issue and not filename related.

Share this post


Link to post
Share on other sites

@horst On a different page (from the same site of course) I've upload the image with the original filename _MG_6550_copy.jpg and the cropping works properly. Also, the button preview will not always update. This is really messed up and tomorrow I have to give access to my client so he can start adding content. If he gets those issues I guess I will uninstall the module and use the core images field with the fixed crops.

Share this post


Link to post
Share on other sites

You mean the button preview hover image is not updating or the icon-size one on the crop button? If the latter, is there a js error? Could you share the preview img filename?

Share this post


Link to post
Share on other sites
17 minutes ago, tpr said:

You mean the button preview hover image is not updating or the icon-size one on the crop button? If the latter, is there a js error? Could you share the preview img filename?

The hover on button is always displaying the correct image. The problem is on the icon-size one. I do not get any js error but sometimes I'm getting this filename: test.-thumbnail.0x48.jpg while others I'm getting this: test.-thumbnail.jpg. I noticed when it's properly working it starts with this: test.-thumbnail.jpg, then with this test.-thumbnail.jpg?v=1, then with this test.-thumbnail.jpg?v=2 but If the page refreshed and crop again it starts again with test.-thumbnail.jpg, test.-thumbnail.jpg?v=1, test.-thumbnail.jpg?v=2 but without displaying the correct image.

Share this post


Link to post
Share on other sites

Thanks, these filenames are OK at first sight, but it's the JS workaround that is failing (so it's not horst :)).

I wasn't able to entirely duplicate the issue but if I uploaded an image and set a crop without saving the page itself first, there was a JS error that prevented the preview to update (uninitialized tooltip). I've fixed it here, so please try updating this file:

https://github.com/rolandtoth/CroppableImage3/blob/master/InputfieldCroppableImage3/InputfieldCroppableImage3.js

If this doesn't help, you could hide the preview image until a better fix (eg. with some admin CSS).

  • Like 1

Share this post


Link to post
Share on other sites
12 minutes ago, tpr said:

Thanks, these filenames are OK at first sight, but it's the JS workaround that is failing (so it's not horst :)).

I wasn't able to entirely duplicate the issue but if I uploaded an image and set a crop without saving the page itself first, there was a JS error that prevented the preview to update (uninitialized tooltip). I've fixed it here, so please try updating this file:

https://github.com/rolandtoth/CroppableImage3/blob/master/InputfieldCroppableImage3/InputfieldCroppableImage3.js

If this doesn't help, you could hide the preview image until a better fix (eg. with some admin CSS).

The problem still exists. The icon-size is useful for me only on repeaters where the button hover image isn't displaying at all.

Share this post


Link to post
Share on other sites

Is the issue present only with repeaters?

Share this post


Link to post
Share on other sites
44 minutes ago, tpr said:

Is the issue present only with repeaters?

If you mean the icon-size issue I haven't test it on repeaters. I'm just saying that if it will ever work for me it will be useful on repeaters since there is a bug there where the hover isn't triggered.

Share this post


Link to post
Share on other sites

@horst @tpr Here is why the cropping result is always different from the area I selected:

cropping_issue.thumb.jpg.c9b1e4c0747e0d99157b645fb86c875b.jpg

On the cropping modal it loads a cached image version where I previously had the image dimensions at 1244 x 829 pixels but currently it's 1400 x 933 pixels. If the non-cache image is loaded I bet it will fix the problem.

Share this post


Link to post
Share on other sites

Have you modified the crop size earlier? If I remember right then the existing crops should be deleted by the module but @horst can tell the truth :)

Share this post


Link to post
Share on other sites

I can't really follow what is it are you speaking of. ?

Is a Screenshot available?

Share this post


Link to post
Share on other sites
2 hours ago, horst said:

I can't really follow what is it are you speaking of. ?

Is a Screenshot available?

Can't you see the screenshot I posted above? The modal cropping should load the non-cache version of the image with the last modified timestamp. 

Currently it loads the image like this which is wrong as here we get the very first cache version of the image with it's previously dimensions 1244 x 829 pixels:

<div class="jcrop-holder" style="width: 1244px; height: 829px; position: relative; background-color: rgb(0, 0, 0);">
<img src="/mysite/site/assets/files/1028/mg_6550_copy.jpg" style="border: none; margin: 0px; padding: 0px; position: absolute; width: 1244px; height: 829px; top: 0px; left: -139px;">
<img src="/mysite/site/assets/files/1028/mg_6550_copy.jpg" data-width="1400" data-height="1050" alt="" style="border: none; margin: 0px; padding: 0px; position: absolute; width: 1244px; height: 829px; opacity: 0.6;">

 

But since I changed the dimensions from the field settings it should be loaded like this with the current image dimensions 1400 x 933 pixels:

<div class="jcrop-holder" style="width: 1400px; height: 933px; position: relative; background-color: rgb(0, 0, 0);">
<img src="/mysite/site/assets/files/1028/mg_6550_copy.jpg?nc=1504572955" style="border: none; margin: 0px; padding: 0px; position: absolute; width: 1400px; height: 933px; top: 0px; left: -139px;">
<img src="/mysite/site/assets/files/1028/mg_6550_copy.jpg?nc=1504572955" data-width="1400" data-height="1050" alt="" style="border: none; margin: 0px; padding: 0px; position: absolute; width: 1400px; height: 933px; opacity: 0.6;">

 

Share this post


Link to post
Share on other sites

@horst I fixed the cache problem on cropping by replacing the 145 line on ProcessCroppableImage3.module with this:

'imageUrl' => $imageUrl . "?nc=" . $img->mtime,

I noticed that the Variations page is showing cached versions of my images too. I think all this is caused by Cloudflare's cache. I guess I have to find out how to disable it on the admin section of PW.

EDIT: Since the images have the same url on both frontend and backend then there is no point to disable cache on backend right? The solution would be to add "?nc=" query on the Variations images too. The Variations page belongs to the core, not to your module right?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Gadgetto
      SnipWire - Snipcart integration for ProcessWire
      Snipcart is a powerful 3rd party, developer-first HTML/JavaScript shopping cart platform. SnipWire is the missing link between Snipcart and the content management framework ProcessWire.
      With SnipWire, you can quickly turn any ProcessWire site into a Snipcart online shop. The SnipWire plugin helps you to get your store up and running in no time. Detailed knowledge of the Snipcart system is not required.
      SnipWire is free and open source licensed under Mozilla Public License 2.0! A lot of work and effort has gone into development. It would be nice if you could donate an amount to support further development:

      Status update links (inside this thread) for SnipWire development
      2020-07-03 -- SnipWire 0.8.7 (beta) released! Fixes some small bugs and adds an indicator for TEST mode 2020-04-06 -- SnipWire 0.8.6 (beta) released! Adds support for Snipcart subscriptions and also fixes some problems 2020-03-21 -- SnipWire 0.8.5 (beta) released! Improves SnipWires webhooks interface and provides some other fixes and additions 2020-03-03 -- SnipWire 0.8.4 (beta) released! Improves compatibility for Windows based Systems. 2020-03-01 -- SnipWire 0.8.3 (beta) released! The installation and uninstallation process has been heavily revised. 2020-02-08 -- SnipWire 0.8.2 (beta) released! Added a feature to change the cart and catalogue currency by GET, POST or SESSION param 2020-02-03 -- SnipWire 0.8.1 (beta) released! All custom classes moved into their own namespaces. 2020-02-01 -- SnipWire is now available via ProcessWire's module directory! 2020-01-30 -- SnipWire 0.8.0 (beta) first public release! (module just submitted to the PW modules directory) 2020-01-28 -- added Custom Order Fields feature (first SnipWire release version is near!) 2020-01-21 -- Snipcart v3 - when will the new cart system be implemented? 2020-01-19 -- integrated taxes provider finished (+ very flexible shipping taxes handling) 2020-01-14 -- new date range picker, discount editor, order notifiactions, order statuses, and more ... 2019-11-15 -- orders filter, order details, download + resend invoices, refunds 2019-10-18 -- list filters, REST API improvements, new docs platform, and more ... 2019-08-08 -- dashboard interface, currency selector, managing Orders, Customers and Products, Added a WireTabs, refinded caching behavior 2019-06-15 -- taxes provider, shop templates update, multiCURL implementation, and more ... 2019-06-02 -- FieldtypeSnipWireTaxSelector 2019-05-25 -- SnipWire will be free and open source Plugin Key Features
      Fast and simple store setup Full integration of the Snipcart dashboard into the ProcessWire backend (no need to leave the ProcessWire admin area) Browse and manage orders, customers, discounts, abandoned carts, and more Multi currency support Custom order and cart fields Process refunds and send customer notifications from within the ProcessWire backend Process Abandoned Carts + sending messages to customers from within the ProcessWire backend Complete Snipcart webhooks integration (all events are hookable via ProcessWire hooks) Integrated taxes provider (which is more flexible then Snipcart own provider) Useful Links
      SnipWire in PW modules directory SnipWire Docs (please note that the documentation is a work in progress) SnipWire @GitHub (feature requests and suggestions for improvement are welcome - I also accept pull requests) Snipcart Website  

       
      ---- INITIAL POST FROM 2019-05-25 ----
       
    • By Sten
      Hello
      Till now I hacked something with the twig template but it works no more with new PW versions so I look forward to create a module. I am working on a site in multiple languages : French, English, Italian, German, Spanish, Portuguese, Hebrew, Russian. The new posts are entered in any language with a field for language. Till now, I got twig files to get the translations with constants defined for each part of the pages.
      So I'd like to create a module to include theses files added according to the url /fr/en/...
      Have you some observations to do before I begin about the direction to take ?
      Thank you
    • By ukyo
      Mystique Module for ProcessWire CMS/CMF
      Github repo : https://github.com/trk/Mystique
      Mystique module allow you to create dynamic fields and store dynamic fields data on database by using a config file.
      Requirements
      ProcessWire 3.0 or newer PHP 7.0 or newer FieldtypeMystique InputfieldMystique Installation
      Install the module from the modules directory:
      Via Composer:
      composer require trk/mystique Via git clone:
      cd your-processwire-project-folder/ cd site/modules/ git clone https://github.com/trk/Mystique.git Module in live reaction with your Mystique config file
      This mean if you remove a field from your config file, field will be removed from edit screen. As you see on youtube video.
      Using Mystique with your module or use different configs path, autoload need to be true for modules
      Default configs path is site/templates/configs/, and your config file name need to start with Mystique. and need to end with .php extension.
      Adding custom path not supporting anymore !
      // Add your custom path inside your module class`init` function, didn't tested outside public function init() { $path = __DIR__ . DIRECTORY_SEPARATOR . 'configs' . DIRECTORY_SEPARATOR; Mystique::add($path); } Mystique module will search site/modules/**/configs/Mystique.*.php and site/templates/Mystique.*.php paths for Mystique config files.
      All config files need to return a PHP ARRAY like examples.
      Usage almost same with ProcessWire Inputfield Api, only difference is set and showIf usage like on example.
      <?php namespace ProcessWire; /** * Resource : testing-mystique */ return [ 'title' => __('Testing Mystique'), 'fields' => [ 'text_field' => [ 'label' => __('You can use short named types'), 'description' => __('In file showIf working like example'), 'notes' => __('Also you can use $input->set() method'), 'type' => 'text', 'showIf' => [ 'another_text' => "=''" ], 'set' => [ 'showCount' => InputfieldText::showCountChars, 'maxlength' => 255 ], 'attr' => [ 'attr-foo' => 'bar', 'attr-bar' => 'foo' ] ], 'another_text' => [ 'label' => __('Another text field (default type is text)') ] ] ]; Example:
      site/templates/configs/Mystique.seo-fields.php <?php namespace ProcessWire; /** * Resource : seo-fields */ return [ 'title' => __('Seo fields'), 'fields' => [ 'window_title' => [ 'label' => __('Window title'), 'type' => Mystique::TEXT, // or InputfieldText 'useLanguages' => true, 'attr' => [ 'placeholder' => __('Enter a window title') ] ], 'navigation_title' => [ 'label' => __('Navigation title'), 'type' => Mystique::TEXT, // or InputfieldText 'useLanguages' => true, 'showIf' => [ 'window_title' => "!=''" ], 'attr' => [ 'placeholder' => __('Enter a navigation title') ] ], 'description' => [ 'label' => __('Description for search engines'), 'type' => Mystique::TEXTAREA, 'useLanguages' => true ], 'page_tpye' => [ 'label' => __('Type'), 'type' => Mystique::SELECT, 'options' => [ 'basic' => __('Basic page'), 'gallery' => __('Gallery'), 'blog' => __('Blog') ] ], 'show_on_nav' => [ 'label' => __('Display this page on navigation'), 'type' => Mystique::CHECKBOX ] ] ]; Searching data on Mystique field is limited. Because, Mystique saving data to database in json format. When you make search for Mystique field, operator not important. Operator will be changed with %= operator.
      Search example
      $navigationPages = pages()->find('my_mystique_field.show_on_nav=1'); $navigationPages = pages()->find('my_mystique_field.page_tpye=gallery');
    • By Robin S
      This is a module I made as an experiment a while ago and never got around to releasing publicly. At the time it was prompted by discussions around using Repeater fields for "page builder" purposes, where the depth feature could possibly be used for elements that would be nested inside other elements. I thought it would be useful to enforce some depth rules and translate the depth data into a multi-dimensional array structure.
      I'm not using this module anywhere myself but maybe it's useful to somebody.
      Repeater Depth Helper
      This module does two things relating to Repeater fields that have the "Item depth" option enabled:
      It enforces some depth rules for Repeater fields on save. Those rules are:
      The first item must have a depth of zero. Each item depth must not be more than one greater than previous item depth. It provides a RepeaterPageArray::getDepthStructure helper method that returns a nested depth structure for a Repeater field value.
      Helper method
      The module adds a RepeaterPageArray::getDepthStructure method that returns a multi-dimensional array where the key is the page ID and the value is an array of nested "child" items, or null if there are no nested children.
      Example

      The module doesn't make any assumptions about how you might want to use the depth structure array, but here is a way you might use it to output a nested unordered list.
      // Output a nested unordered list from a depth structure array function outputNestedList($depth_structure, $repeater_items) { $out = "<ul>"; foreach($depth_structure as $page_id => $nested_children) { $out .= "<li>" . $repeater_items->get("id=$page_id")->title; // Go recursive if there are nested children if(is_array($nested_children)) $out .= outputNestedList($nested_children, $repeater_items); $out .= "</li>"; } $out .= "</ul>"; return $out; } $repeater_items = $page->my_repeater; $depth_structure = $repeater_items->getDepthStructure(); echo outputNestedList($depth_structure, $repeater_items);
       
      https://github.com/Toutouwai/RepeaterDepthHelper
      https://modules.processwire.com/modules/repeater-depth-helper/
    • By MoritzLost
      Cacheable Placeholders
      This module allows you to have pieces of dynamic content inside cached output. This aims to solve the common problem of having a mostly cacheable site, but with pieces of dynamic output here and there.  Consider this simple example, where you want to output a custom greeting to the current user:
      <h1>Good morning, <?= ucfirst($user->name) ?></h1> This snippet means you can't use the template cache (at least for logged-in users), because each user has a different name. Even if 99% of your output is static, you can only cache the pieces that you know won't include this personal greeting. A more common example would be CSRF tokens for HTML forms - those need to be unique by definition, so you can't cache the form wholesale.
      This module solves this problem by introducing cacheable placeholders - small placeholder tokens that get replaced during every request. The replacement is done inside a Page::render hook so it runs during every request, even if the response is served from the template cache. So you can use something like this:
      <h1>Good morning, {{{greeting}}}</h1> Replacement tokens are defined with a callback function that produces the appropriate output and added to the module through a simple hook:
      // site/ready.php wire()->addHookAfter('CachePlaceholders::getTokens', function (HookEvent $e) { $tokens = $e->return; $tokens['greeting'] = [ 'callback' => function (array $tokenData) { return ucfirst(wire('user')->name); } ]; $e->return = $tokens; }); Tokens can also include parameters that are parsed and passed to the callback function. There are more fully annotated examples and step-by-step instructions in the README on Github!
      Features
      A simple and fast token parser that calls the appropriate callback and runs automatically. Tokens may include multiple named or positional parameters, as well as multi-value parameters. A manual mode that allows you to replace tokens in custom pieces of cached content (useful if you're using the $cache API). Some built-in tokens for common use-cases: CSRF-Tokens, replacing values from superglobals and producing random hexadecimal strings. The token format is completely customizable, all delimiters can be changed to avoid collisions with existing tag parsers or template languages. Links
      Github Repository & documentation Module directory If you are interested in learning more, the README is very extensive, with more usage examples, code samples and usage instructions!
×
×
  • Create New...