homepage slide images (repeater + cropmodule) not showing if guest

[onjegolders]

Just realised that if I'm not logged in, then my images for my homepage slider (which is a repeater field with its images using the Crop module) don't show.

I'm using the latest dev version of PW and am thinking this may well be to do with the new protected file system? My home template is accessible though so not to sure on where to go next?

[diogo]

What doesn't show, only the images or the repeaters themselves? Are you able to echo the titles for instance?

[onjegolders]

Hi Diogo, thanks for replying. Yes the other repeater content outputs just fine.

[diogo]

what about if you output the image normaly, without using the getThumb() method?

edit: also, try to access the images directly, by pointing the browser to their url. Both, full version and cropped.

[onjegolders]

Strange I'm getting this as my img url:

http://localhost/pw_template/admin/repeaters/for-field-134/for-page-1/1354274914-77-1/-/full_hands.jpg

which is showing when logged in but giving me a 404 when not

If I output normally with url, I still get blank images

[ryan]

That's a bug (glad we have a dev branch). I'll work on this.

[onjegolders]

Thanks Ryan!

[ryan]

Okay I think I've got this fixed. Would you mind trying it out and seeing if it also fixes it on your end too? It is on the latest commit to the dev branch.

https://github.com/ryancramerdesign/ProcessWire/commit/7dab612baa55b7ca02a7d6679e70d1aef4298f8b

It involved a re-thinking of what a repeater Page is. I've changed it so that repeater pages are now represented by their own class (RepeaterPage rather than Page). The new RepeaterPage is the same thing as a Page, but overrides the method used to determine when files should be secured or not (which it now delegates to its owning 'for' page) . It also adds 2 methods (see below) so that people don't have to do stuff like this to figure out what Page or Field a given repeater item belongs to. For those interested, these methods now appear on all repeater item pages:

$page->getForPage(); // returns the owning Page this repeater item is for
$page->getForField(); // returns the Field this repeater item belongs to

[onjegolders]

Thanks Ryan that's sorted it.

Am having another (sorry ) issue thought it could just be related to the crop module (and maybe I should post there?)

If I try and edit the thumbnail before page save then I get an "invalid file" error.

If I save the page and then edit the thumbnail, it all seems to work. I don't remember it working this way before, but may be wrong.

[ryan]

If I try and edit the thumbnail before page save then I get an "invalid file" error.

If I save the page and then edit the thumbnail, it all seems to work. I don't remember it working this way before, but may be wrong.

I just tried to reproduce this, but am not experiencing that particular issue here. Are there any other factors, like the page being unpublished or something?

[onjegolders]

Hmm nope, definitely published.

It's a Cropimage field in a repeater in a fieldset Tab on the latest dev version.

Not sure else what could affect it?

[ryan]

You might try moving it out of the tab, just to see, though I doubt that's it. If you are using an admin theme other than the default, you might also try switching back to the default, just in case. Lastly, double check that there aren't any errors in your JS console. Since you are no longer stuck, as it all starts working after you save, and I've not been able to reproduce it here, lets wait and see if someone else can. That might give more clues how to reproduce it.

[onjegolders]

Hiya Ryan, not getting any JS errors, this is the link for the second window http://localhost/pw_template/admin/page/image-crop/?filename=20121012_101025.jpg&prefix=full&width=1200&height=%20380&pages_id=1&field=image&modal=1

Moving it out of the tab doesn't have any effect, can only think that the file isn't getting set until page save?

[Alex]

Hi onjegolders,

Was this ever solved?, I am also getting 'invalid file' error when i try and crop an image in a repeater before I save the page.

The page is published and i'm using the thumbnails module, processwire 2.3

Do we need to save page after each upload in a repeater?

[vsulin]

Hi all,

I also ran into a problem with Thumbnails module cropimage field inside a repeater.

It does work with superuser account, but when I log in with an account that has all full access to root template (all other public pages have no access rules) and all but "Administer users"-permission.

It gives the following error when trying to crop an image manually: Not Editable

The given error is twice in ProcessCropImage.module. This is the first one at line 58. I think it might be trying to check the "repeated page" and not the actual page for access. So the access from root/parent isn't inherited correctly to "pages inside repeater"? Or is the logic wrong when working with repeater-fields?

[ryan]

What version of PW are you running? I'll assume PW 2.3 stable unless you say otherwise. I think you may be right about the editable() check though. Though it looks to me like the module is performing the correct check. I might need to re-think a hook in FieldtypeRepeater to Page::editable. For now, try pasting this at the top of your /site/templates/admin.php:

wire()->addHookAfter('Page::editable', function($event) {
  if($event->return) return; 
  $page = $event->object;
  if($page instanceof RepeaterPage) {
    $event->return = $page->getForPage()->editable(); 
  }
}); 

Let me know if that fixes it?

[vsulin]

it is 2.3 stable.

I added the given code before the default code and it gives the following error when just reloading the edit-page:

/processwire/page/edit/    Error:  Method name must be a string (line 293 of wire/core/Wire.php)

[Radek]

ryan, on 09 Jun 2013 - 14:27, said:

What version of PW are you running? I'll assume PW 2.3 stable unless you say otherwise. I think you may be right about the editable() check though. Though it looks to me like the module is performing the correct check. I might need to re-think a hook in FieldtypeRepeater to Page::editable. For now, try pasting this at the top of your /site/templates/admin.php:

wire()->addHookAfter('Page::editable', function($event) {
  if($event->return) return;
  $page = $event->object;
  if($page instanceof RepeaterPage) {
    $event->return = $page->getForPage()->editable();
  }
});

Let me know if that fixes it?

Hi Ryan, i have same problem. Another users than admin can not edit cropimage field in repeater.

I tested your suggestion, but not working...

Soma helped me thrue IRC and this workaround works for me:

wire()->addHookAfter('Page::editable', null, 'hookEditable');
function hookEditable($event) {
    if($event->return) return;
        $page = $event->object;
    if($page instanceof RepeaterPage) {
        $event->return = $page->getForPage()->editable();
    }
}

We tested some changes like:

if(!wire("pages")->get((int) $this->input->get->pages_id)->editable()) throw new WirePermissionException('Not Editable');

or

if(!$page->getForPage()->editable()) throw new WirePermissionException('Not Editable');

in ProcessCropImage.module (execute and executeSave functions) but more work will need to be done in cropimage module.

[onjegolders]

Hi onjegolders,

Was this ever solved?, I am also getting 'invalid file' error when i try and crop an image in a repeater before I save the page.

The page is published and i'm using the thumbnails module, processwire 2.3

Do we need to save page after each upload in a repeater?

Hi Alex, I still have the same issue, have to save the page before editing the crop.

[vsulin]

Hi Ryan, i have same problem. Another users than admin can not edit cropimage field in repeater.

I tested your suggestion, but not working...

Soma helped me thrue IRC and this workaround works for me:

wire()->addHookAfter('Page::editable', null, 'hookEditable');
function hookEditable($event) {
    if($event->return) return;
        $page = $event->object;
    if($page instanceof RepeaterPage) {
        $event->return = $page->getForPage()->editable();
    }
}

Hi,

this also fixed it for me. I'll see if I can fix the module to work without the workaround now that were certain on the cause.

As for the not being able to crop the image without saving. I don't really see that as a real problem.

[ryan]

I added the given code before the default code and it gives the following error when just reloading the edit-page:

/processwire/page/edit/    Error:  Method name must be a string (line 293 of wire/core/Wire.php)

Sorry, I should have realized and mentioned: the code I posted requires ProcessWire 2.3 and PHP 5.3+. Thanks to Soma, you've also got the version that is compatible with PW 2.2.9 and PHP 5.2, above. 

[Arklogic]

Still nothing with this error?

I've the same here.

Just an idea: maybe the 'invalid field' comes out because the image we uploaded is not saved to the page, so the cropimage modul can't decide which image should be cropped...