douglas81

Yep, that's it fixed. Thanks again Ryan!

No, it's more serious than that. It literally doesn't leave the page edit dialog. I'm not using any of the fancy stuff yet

(Someone has just added the issue to Github, so I'm sure Ryan will work his usual magic and come up with a timely solution.)

Ah, good to know it's not just me. I was running the stable PW, but the new image and comments features caught my eye so I thought I'd give the newest dev branch a shot. Do you know, is it safe enough to revert back to an earlier dev? Could that really mess things up?

Here's a weird thing. It's not just new fields I've created since upgrading to the new dev, it's the same problem with every image. I can't delete anything! No error messages, nothing. I click the trash button and it goes red and scores it out like normal. But then hit save and it just comes back like I didn't do anything. How curious. I don't think it's file permissions or anything like that because I haven't changed anything on the site directory. Just replaces the wire directory, as normal.

Hope somebody can help me out here. Dev 2.5.19 great so far apart from this quirk... I created an image field, like normal. I added it to a template, as normal. I go to edit the page in question, upload the image. Everything great. Except now I can't delete the image. It just stays there on page save. Any ideas? Is this a known bug with the latest PW dev? Everything else seems fine. Using Reno's theme, if that make's a difference? Douglas. P.S. just tried it with default theme and no difference.

Yeah, it's quite involved. I'm afraid a lot of what you said doesn't quite make sense to me you. I'm still getting my head around hooks and making my own modules in PW (I've done a couple, but it's always a bit "black magic" for me at the moment). What I was thinking, is to use JS to grab all the relevant stuff from the form, POST it using AJAX to my own custom PHP. This PHP will take the POST data, analyse it, add the comment if everything is okay. It will return a success or failure message. Then, again using JS, update a DIV with the returned message. Of course, this doesn't account for adding the comment. If it was automatically approved without moderation, I could always just update the relevant DIV, again with JS.

The current default for the Comments module seems to be... 1.) User enters name, email and comments 2.) User hits submit 3.) Page is refreshed 4.) Thank-you message or error message returned How do we avoid step 3, the page refresh? Is it possible with the standard commenting system? Some sort of AJAX must be involved, but I don't know if it's possible to modify the current comments system to accommodate this. Any pointers much appreciated.

That's a pity, but I understand it's perhaps a marginal feature. Although, for people offering large digital downloads, Amazon S3 is pretty much the standard way to do things. Aside from that, any insight into how digital downloads are working? What's the checkout and delivery process like?

I don't think it's a huge problem for people to see where the file is coming from, so long as the link generated is time and download attempt limited.

I'm not sure the ins and outs of it. I have been using SendOwl, and it works flawlessly. You just provide your S3 KEY and SECRET and SendOwl does the rest. Here's their info page on it... http://help.sendowl.com/article/23-using-self-hosting Something like that would be perfect. I have no idea what's going on behind the scenes there though. I was very happy with SendOwl, but I'm very keen to get everything within ProcessWire admin.

Hi Apeisa, Great to see you are approaching release of this. I'll be launching a site in Q2 2015 and can't wait to try out this module. I'm wondering how things are going with the digital downloads? It would be great to hear some more info about how that works and how flexible it is. Also, I'm hoping to offer high-resolution audio downloads, and these can be quite large files (500 MB plus). I would like to use Amazon S3 for delivery, and I'm wondering if that's going to be a possibility? Cheers! Douglas. P.S. sorry I didn't get a chance to check out the beta. Actually, I've been away from coding for a couple of months, so everything in that regard has been on hiatus.

Maybe I'm missing something obvious, but how does one go about pre-populating the input fields?

Ah, didn't know that, thanks! But I think the second option "who can access this page" is the solution. You can set up any number of permissions there on a user-by-user, page-by-page basis should you desire.

I'm guessing you're talking about allowing back-end users the ability to only view unpublished pages, but not be allowed to edit them. I remember wondering about this myself on day one of ProcessWire. Basically, go to the edit view of whatever page you want this view-only behaviour to apply to, then go to the settings tab and in there you'll see under "Status" the option... "Locked: Not editable". Check that, and now the page can be seen but not edited. I think that's what you're looking for. EDIT: Oh yeah, and furthermore, you'll see the extra "who can access this page" options under there where you can adjust specific user permissions on a page-by-page basis.

Hey Jan, Ha ha... yeah, it's sometimes tricky to explain what I'm trying to do...! Basically, as you'd expect, I have image fields in a few of my templates. But I also have a separate php script running outside of the usual ProcessWire stuff which processes those images that were uploaded to PW's assets folder via the image field. When a user deletes the original image, I just want to make sure these modified images are automatically found and also get deleted. It seems like there are specific rules about how I must rename the processed files in that case. That's what I'm trying to work out.

From my own research, it seems like appending something thus... "originalimagename.appended.jpg" ... doesn't work. It seems like we need to have dimensions after the originalname, so... "originalname.600x400-appended.jpg" works fine. However, "originalname.600x400.appended.jpg" doesn't work. It seems that apart from the final period before the file extension, we can only have only one extra period and that must directly precede the image dimensions. I guess that's just how the regex is working, right? So, I've determined this... I can modify the filename however I want, so long as there is one period directly after the original file name, and the first info after that added period is the image dimension, and directly after the image dimensions before any appended info, we must have a dash. Sound about right? Also, it seems like I can't have the @ symbol in there. Which is a shame as I sometimes like to use that for "retina" optimised images. Any other limitations and/or naming conventions I should know about?

I would like to put a few page images through third party image processing tools via php's exec() function. This will generate a new file which I would like to store in the same folder as the original. If I should ever delete the original image, I don't want to be left with orphaned variations. So what naming conventions or procedures must be in place that will allow these image variations to be deleted if I should choose to delete the original through the admin?

Calling AIOM/chmod experts... Just today a whole website of mine using AIOM ceased to function. Precicely 1 month after installing AIOM on the site, I was getting a 500 error. Looking at the PW log file I saw countless repetitions of... 2014-10-18 15:59:18 guest http://***.com/?/ Error: Exception: The permissions (chmod) to delete old cache files could not be changed. (in /srv/***/www/***.com/public_html/site/modules/AllInOneMinify/AllInOneMinify.module line 646) So, I guess one or more of my cached files had hit a 30 day expiry date. I did a bit of investigating, and it seems that before deleting cache files, AIOM like to chmod 777 the file. If it can't chmod the file, it throws this error and stops the site loading. No logging into PW admin, nothing. It seems similar to this problem here: https://github.com/ryancramerdesign/ProcessWire/issues/648 And the exact line of code in question is highlighted by Ryan there. https://github.com/FlipZoomMedia/ProcessWire-AIOM-All-In-One-Minify/blob/AIOM%2B/AllInOneMinify.module#L641... It's line 646. Is there any real need to change the permissions to 777 before deleting? The problem in my case is that www-data doesn't own these files. I copied this installation over from another server, and the owner (chown) is actuall "admin". But I have group rw permission to www-data, so the files can be deleted. I think that should be okay, right? So, what I did was comment line 646 and added the following three lines // ------------------------------------------------------------------------ // Remove all files that are older than the maximum lifetime. // ------------------------------------------------------------------------ foreach ($_cacheFiles as $_cacheFile) { if (((filemtime(wire('config')->paths->assets.self::$cacheDir.DIRECTORY_SEPARATOR.$_cacheFile->getFilename()) + self::$cacheMaxLifetime) < time() OR $force_all === true) AND is_file($_cacheFile)) { $_file = wire('config')->paths->assets.self::$cacheDir.DIRECTORY_SEPARATOR.$_cacheFile->getFilename(); if(chmod($_file, 0777) !== false) { if(unlink($_file) === false) { throw new WireException('The old cache files could not be deleted.'); } } else { // throw new WireException('The permissions (chmod) to delete old cache files could not be changed.'); if(unlink($_file) === false) { throw new WireException('The old cache files could not be deleted.'); } } } } And now everything seems to work again. Stuff like this sort of scares me. The last thing I want is for sites to completely and arbitrarily stop working!

I'll have a poke around a bit more and see if I can get it going myself. I think I'm starting to understand it.

Hey, wait a minute. I'm pretty new to GET and POST and I suddenly realise I've made a huge incorrect assumption! Ha ha. I thought POST and GET were two sides of the same coin. I thought you used POST to "post" the data to the URL string and GET to "get" the data from the URL string. Obviously I'm wrong. Seems like POST appends the data to the http request, right? So, what I want to do is get the form to $_POST the relevant info. I just don't really know how to do that! Man, now I'm feeling like a total newbie again.

Ah yeah, I see that now. A follow up question, then... Obvisouly I'm trying to set this up so that the file is only downloadable if a form has been filled in. As you'll see from the original post, I thought of doing this with some sort of URL POST from the form. But that then gives a URL which somebody could easily share and somebody else could use without going through the original page. (Does that make sense?) For example, I just did a little test where on submitting the form, we are redirected to this URL website.com/file.pdf?agreed=true and we have this in our PHP... $agreed = $_GET['agreed']; if($agreed == 'true') { wireSendFile($page->pdf->filename); } else { die("not allowed, sorry"); } It works great. The only problem is somebody could just copy that link and give it to somebody else. They wouldn't need to go through the original page containing the form. I wonder if using some sort of "behind the scenes" webhook would be the way to achieve this? I just have no idea how as I've never done something like that before.

Yeah, it looks pretty flexible. One thing, though. Is there a way of sort of hiding the file location? I guess not really. I mean, when the user has actually started downloading the file, won't they see the actual file URL?

Okay, so here's what I'm thinking... I'll use Soma's idea and create download files as pages https://processwire.com/talk/topic/4602-flexible-downloads-using-pages/ — thanks again for that link! Then, we'll make sure any page we want to have a download link on uses a template which has a page field where we can select a download page. Then, to do the "accept terms before download" bit... The php for the page containing the download link will also have a form in it which takes the users name, e-mail address and a checkbox for agreeing to the terms. Hitting the submit button will create a URL POST with name, e-mail, checkbox boolean from the form. That's going to either open up or ajax the Soma-style download page (e.g. file.pdf?agree=true&email=info@mail.com). The associated template php will evaluate that URL (using _GET), and if it's all good, we release the download using: if($page->pdf){ wireSendFile($page->pdf->filename); } Does that sound like it's gonna work?

Great stuff to go on, thanks!