Tyssen

Thanks, that was it. ? parent.parent didn't work but I did a find on the template instead.

I'm outputting the items in an ordered list so that's showing the count for me. The max number it displays is 50. I've temporarily disabled the site's prepend and append files so the only thing showing on the page now is the output from the selector I posted above. Are there any config settings either in config.php or in the admin which might restrict the number?

I'm trying to output a long list of pages. If I do this: $subpages = $pages->get('/shop/products/')->child->children; the output is limited to 50 items. If I do this: $subpages = $pages->get('/shop/products/')->child->children('limit=9999'); the output is also limited to 50. But if I enter any number less than 50, then that's how many get displayed. What am I missing?

There's actually two instances of the fieldtype: one on a single page with just a single image, but the bulk of the content of the site, so nearly 600 pages, are using the fieldtype with up to 12 images uploaded per page. I did this, and the new field in the new template worked fine. Do you mean permissions? If so, they seem to be. All 644 with same owner/group.

PW was on v 2.5 and is now on 3.0.148 and CroppableImage was on 0.8.4 Alpha and is now on CroppableImage3 1.2.0, although initially it was upgraded to 1.1.6. This upgrade has been a long, drawn-out process with the client going silent for long periods of time. I did the upgrade locally quite a long time ago so don't have a clear recollection of the exact process I followed. It wasn't until just recently that the problem with uploading was noticed. I think I upgraded PW first not realising that CroppableImage wasn't compatible with PW 3.x. And then replaced the CroppableImage module folder with CroppableImage3 and then updated the fieldtype (there's only one) via the admin. I didn't realise user roles had to be updated and I've just gone through and assigned the Crop images with CroppableImage3 role via the admin. I've obviously made a mess of the upgrade and didn't take enough care of noting the changes I've made. But any advice you could give on how to get out of this hole I've dug for myself would be appreciated.

I upgraded an older version of PW to 3.0.x and in the process upgraded all the associated modules including CroppableImage to CroppableImage3 but somewhere along the way from moving the site from dev to live something has gone wrong because now there are problems uploading images. Sometimes they'll upload and sometimes when you click on the Choose File button, or drag an image into the field, nothing happens. On a test page that already had an image in it, I couldn't get another one to load and there were no errors in the console. After removing the one image and resaving, neither the choose file button or dragging were working. Clicking the choose file button produced no errors, but dragging returned: Uncaught TypeError: can't access property "grid", config.CroppableImage is undefined /site/modules/CroppableImage/InputfieldCroppableImage/InputfieldCroppableImage.js?v=83-1429629453:405 jQuery 7 /site/modules/CroppableImage/InputfieldCroppableImage/InputfieldCroppableImage.js?v=83-1429629453:403 jQuery 11 from InputfieldCroppableImage.js:405:21 I've also just updated to 1.2.0 but the problem still remains. Any idea what I can do to fix it?

@bernhard Presumably the hook for #2 could look the same as the one @kongondo wrote above? It doesn't necessarily need to be a child of a particular page, but instead match a template. And for #3, what would the magic link look like, how would it be generated?

Where's the place to post Promailer questions before purchasing the module? @ryan

So in ready.php it would be something like this? wire()->addHookAfter('Pages::published', function($event) { $page = $event->arguments('page'); $t = wire()->templates->get($page->template); if($t->name == 'blog') { // what goes here? } $event->return = $page; });

So would that still be using a webhook as described in #1 by @kongondo above and using ProMailer for #2? Or does the triggering of emails when pages are published exist in ProMailer already?

I can see that you can use the module to add subscribers to a Mailchimp list, but it seems like you could just use a Mailchimp form to do that. I'm not seeing anything in there about there being a link between publishing content in Processwire and then subscribers receiving emails about that event.

So is the idea to use Mailchimp's RSS to email feature?

Does anything exist within PW for people to be able to subscribe to updates? So you enter your email address and when new blog posts are published, you get an email alert? And I guess there also needs to be a way for people to unsubscribe too. Does anything exist like that for PW?

I've been using Firefox and not had a problem. Others, who have been getting the problem, have been using Chrome and Safari. I'll have to check with them tomorrow to see whether it's still occurring and then attempt turning things off and on.

No, just a single language. Also, no _init or prepend/append files being used on this site.

Apparently, there's no error messages, they're just redirected back to the login page when logging in.

I have a client who is reporting that in the last couple of days they can no longer login to their site with their normal browser (Chrome). Using another browser or an incognito window works. I've tried logging into the site using the same login details in my usual browser (Firefox) and have had no problems. The site is a membership site and today other members are reporting the same problem. The site is running 3.0.148 and has the session handler DB and login throttle modules installed. It was recently upgraded to 3.x from 2.x. But no changes have been made to the site between the time when they were able to login OK and when the problem started happening.

Same. Any news on if this is likely to be included?

Thanks. matrixBlock.fieldName.first.value was what I was after. ?

I have a repeater matrix field on a page and one of the matrix types has an options fieldtype. If I do {{ matrixBlock.fieldName }} I get the numeric value of the selected option. But if I do {{ matrixBlock.fieldName.value }} (or title) I get: Any ideas?

I've come back to this module again for a project I'm working on and I'm finding that when I'm working locally, any pages that are calling srcset take ages to render. I thought it was just because it's taking a while for PW to process all the different image sizes but it happens every time I reload the page. If I remove the images, the page loads quickly. This doesn't happen on the production server where pages load fine, it's just on my local setup. Any idea what might be causing that?

Don't you hate it when the answer to the problem turns out to be really stupid? I had `require '../vendor/autoload.php'` in config-dev.php so it was working fine locally but not in config.php on the server. ?

Even though I dove into this nearly a year ago on my local dev server, I never actually got around to using it on a production site until now. And now when I try to run on the live server I get: File: .../public_html/site/templates/_init.php:4 $twig_main_dir = $config->paths->site . 'templates/'; $twig_loader = new \Twig\Loader\FilesystemLoader($twig_main_dir); Any ideas what I need to do to clear up that error? I've run `composer update` on the server and also `composer dump-autoload`.

Yep, that was it, thanks. ?

So I've kinda got stuck with this which I've described in another thread: