netcarver

I think either way would work. Your suggestion is change the label client-side, mine was leading towards changing it server side.

That was quick blad! I was just about to post the following... But your's is another approach again.

Hi MrEd, Thanks for posting this to the forum! Could you raise an issue on the ProcessWire github repository for this please? You'll need to add a little more information though - like what version of PW this applies to. Thank you and hope this gets resolved for you soon.

If you want to move beyond just scattering echo or print_r through your code then the first step is getting xdebug installed in your PHP layer. After that you can use any debugger that supports it - several have already been mentioned. Personally, I like to use the vdebug extension inside vim. Single steps very well, you can set breakpoints on lines or conditions and inspect local and global variables as needed.

Ah, OK. Well, that depends on where the $msg1 and $emailTo fields come from and if you trust them to never have anything malicious in them. If they can have something malicious (like a frontend user entering an email address, or anything that gets made part of $msg1) then, no, this is definitely not "code tight". Always sanitize user input. Please look at PWs sanitizer class; it has methods specifically for making email addresses and general text more "code tight." It's also not code tight as it totally ignores the return value of the mail() call - so you'll never know if the send failed. You can also simplify your example by getting rid of the assignment to $header in the call. Here's the last two points put together. I'll leave the sanitization research to you as it's important you find out about it. $result = mail($emailTo, "Bestellung", $msg1, "MIME-Version: 1.0\r\nContent-type: text/plain; charset=UTF-8\r\n"); if (!$result) { // email send failed. } else { // send succeeded }

@pwired Glad you got it working. Can't answer your question as I have no idea what "100 % code tight" means.

How is the email being sent? PHP's mail() function, PW's wiremail or a third party solution? If it's PHP's mail() function are you sending a charset as part of your content-type header?

I don't know if that will fix your exact problem - it might if your product field has a space in it. I do know that the way you are outputting a user-supplied field as part of a URL could generate invalid URLs. For example, If a user ever entered anything other than a-z, A-Z, 0-9, _, -, ~ or . in your product field you could find yourself with a potentially troublesome url - especially if that field had an '&' in it. If that were the case and you keep constructing the urls like that you'll find there's an extra get parameter for each '&' in your product field; probably not what you want. More on wikipedia.

@horst: Done for set_time_limit(). DiagnosePhp.module now at v0.0.4

@Peter, You should pass the values from $page->product through a url sanitizer. If there are any spaces in the product field you'll get a dud url doing it like that. $url = wire()->sanitizer->url($page->product); You could pass the price field through the sanitizer too - no harm in that.

How about this:

@horst, don't know if it does or not. Here's another possible starting point though: set_time_limit() Update1: Looks like you might be right according to this on Stack Overflow. @nico, there are some apache config options to check in there too. Update2: Added the timeouts to DiagnosePhp.module as well.

Nico, is the upload taking longer than the max runtime of PHP scripts?

@nico, I'll add those lines. Update: Done, added to DiagnosePhp.module.

Not really an answer, but perhaps this can help.

@adrian Works great here now. Thank you for the work on this module!

Hi Adrian, The 2¢ solution seems to be working just great. I'm still getting the stray field at the end of the child templates with 0.1.8 though. The field it creates looks quite interesting in the child template... Edited to add: I think I found the issue. I've added a comment to your repo, here, about it and also opened an issue against PW to allow incompletely defined fields to be deleted via the admin interface.

<2¢> Can only add a tiny idea at the moment. Currently the "Child Template Name Override" field says... Seeing as your module knows what the suffix is, why not either tell the user what the template will be called if they don't enter a value or... make the field required and setup the value to what will be used? In either case your users get to see exactly what will be used for the template and can change it if they don't like it. At the moment they have to guess or else navigate away from the page in order to see if they like the template name that will be used. </2¢>

Hi Adrian, Here it is... Title, Tel>Text, Steve, ...and I think I see the issue. There's a trailing comma with no fieldname after it on the first line. Stupid typo on my part but probably something you'll need to catch and handle when parsing the string.

@adrian Thank you very much for the update. I've been trying it out and overall, it's excellent! However, I think I might have found an issue. On every child page created using the module I'm seeing a new, untitled field at the foot of every page (I'm trying this in 2.5.1dev using the Reno theme.) Here's an example...

@Nico I really like this module! Great idea.

@clsource, other interested parties I've been busy and haven't got this totally finished yet -- I still need to work on a decent method of getting these counters into a page in PW which probably means a fieldtype/inputfield. The actual counter code is, however, all done for both files and redis. Here's part of the documentation which covers more of what I posted above (essentially an escrow problem.) Any feedback would be appreciated.

@douglas81 You might want to PM Antti (apeisa) via the forum about that too. Not sure on his timescales.

Well, you'll need the wireframes for each of your options so I'd suggest you prepare them then contact Ryan to see if its on his roadmap. If not, the ball is still in your court as to how to proceed.

You are overwriting the $pictures variable in each loop iteration. It will only ever have the last image in it that way. You should concatenate instead. Something like this... if(count($page->images)) { $pictures = ''; // if the page has images on it, loop through them... foreach($page->images as $image) { $image = $image->width(400); $pictures .= "<img src='$image->url' alt='$image->description' />" . "<blockquote>$image->description</blockquote>"; } // output the images at the top of the sidebar $sidebar = $pictures . $page->sidebar; } Note that it is now $pictures .= "..." rather than $pictures = "..."