Wanze

Hi ryan, When one sets the max upload value with the hidden MAX_FILE_SIZE, then the message "Exceeds max allowed file size" never appears. The error UPLOAD_ERR_FORM_SIZE get's caught already on the first line of the WireUpload::isValidUpload method. If we don't put a MAX_FILE_SIZE field, it works. But I remember having read somwhere that when setting the MAX_FILE_SIZE field and the user submits a bigger file, then it is not getting uploaded at all which I think is important. I should have a translation too Maybe moving the initialization of $errorInfo to the constructor, allowing to translate the strings? Or provide a method to get also the error-keys, not only the strings? Thanks <?php //When MAX_FILE_SIZE is sent and the file is too big, it get's caught on this line if($error && $error != UPLOAD_ERR_NO_FILE) $this->error($this->errorInfo[$error]);

Hi Philipp, You can do this Check out the module config options of "InputfieldPageName" - you can actually edit the replacments there.

Writing an answer sometimes the editor doesn't let me create signs that need the "Alt/Options" key to be pressed. For example "@" or "#". I can solve this by leaving the editor, focus something else and then give the focus back to the editor. Not that evil but the first time I almost went crazy Firefox, Mac os x

Since I know Pw my average sleep time's getting shorter and shorter. Yesterday I went to bed @ 23.00, thinking around Pw-Projects and ideas till midnight and finally realized I couldn't sleep – standing up again to do some coding on a new module till 01.30.

if (count($page->Files)) { //... } Because $page->Files is a WireArray and that is casted to "true" by PHP

Coming soon: Pages2Pdf module

Ups Teppo's probably right I didn't think of that loop. Please try with $page->save('files'). Cannot modify my post im on mobile. Another approach would be to create the pdf on first click and then save it. The next clicks can load the saved pdf (cache). Then you just have to delete the pdf on page save to make sure it gets recreated again on the next click.

This would be a modification with the API. So inside your 'writepdf' function, do something like this (this example uses the tcpdf class): require_once('PATH_TO_YOUR_TCPDF_CLASS/tcpdf.php'); $page = $event->arguments[0]; // create new PDF document - taken from an example on tcpdf.org $pdf = new TCPDF(PDF_PAGE_ORIENTATION, PDF_UNIT, PDF_PAGE_FORMAT, true, 'UTF-8', false); $pdf->AddPage(); $html = $page->render(); //Instead of the method below you maybe want to create a "PDF-Template" for your site $pdf->writeHTML($html, true, false, true, false, ''); $filename = $this->config->paths->assets . 'pdf_tmp/' . $page->name . '.pdf'; $pdf->Output($filename, 'F'); //Save the pdf to temp folder //Add the pdf to the page $page->of(false); $page->files->add($filename); $page->save('files'); //Remove temp pdf unlink($filename); I don't think it will work, but something like this should. Does it help?

Hi yesjoar, This sounds like a good idea. You could also check if there were made some modifications to the content fields before creating a new pdf. For creating the pdf's, I can recommend tcpdf. Used it a few times and it has UTF-8 and basic CSS support. Cheers

Maybe a "Payment Module" which handles all the complicated stuff behind. So to take your example: // Payment form was submitted if ($input->post->submit) { $payment = $modules->get('PwPayment'); $payment->method = "PayPal"; // ie. "AuthorizeNet" or "PayPal" etc... $payment->currency = "euro"; //... There must be some abstract base class "Payment" that provides common methods and variables. Maybe an interface too to exaclty define which methods need to be implemented for the different Payments. Then each payment could have its own class extending the base Payment class. Of course the actual implementation would still be hard because of the different ways each payment works. But with a pattern like this, the module could be used anywhere and always has all the implemented Gateways available. Pseudo code: <?php //The Module class PwPayment extends WireData implements Module { protected Payment $payment = null; //Overwerite the magic set method public function __set($key, $value) { if ($key == 'method') { switch ($value) { case 'PayPal': $payment = new PaymentPayPal(); break; } } return parent::__set(); } public function ___process() { return $payment->process(); } } //The abstract class abstract class Payment { public function addJs(); public function process(); public function checkErrors(); } //PayPal Implementation class PaymentPayPal extends Payment { //... }

Hi bcartier, I think this is currently only possible with a little hack. I took a look at the source of Thumbnails and if I'm right, you need to uncomment the if on line 91 here: https://github.com/apeisa/Thumbnails/blob/master/FieldtypeCropImage.module#L91 //if ($this->w != $sizer->getWidth() || $this->h != $sizer->getHeight()) { $this->_copyAndResize($img, $imgPath); //}

Thanks for your feedback raydale. I think providing a link to edit the pages makes sense. I'll add this plus some permission checking in the next version. But I also think that the current system to search the pages with a selector is mainly for superusers. For non-superusers, another search-system would be better. I was thinking of adding the option to create some pre-defined searches as links, which store the selectors behind the scenes. For example: Display posts Display architects This could be done in the module config options with something like this: Display posts||template=post, include=all, sort=-created Display architects||template=architect

My 15" Mac Book Pro from 2010 gets slower and slower and I'm planning to buy a new one soon. SSD, more RAM and a better CPU makes the new McBooks fast. The remaining question is: With or without Retina-Display. Can anyone share some experience with the retina display? For example I know that smaller images on websites look blurry because of the higher resolution of the retina. Also what about apps that aren't optimized for retina: Working with photoshop? Coding? Thanks

Of course! Check out "Using the API to add or remove repeater items" http://processwire.com/api/fieldtypes/repeaters/

You need to remove the "#" in front of ONE RewriteBase (# marks the line as comment) So you should try first: RewriteBase / If it doen't work, add your subdirectory where the Pw-files live. For example, if you have your site at http://localhost/foobar, you would add this line: RewriteBase /foobar/

(¯ `v´ ¯) `·.¸.·´ ¸.·´¸.·¨) ¸.·¨) (¸.·´ (¸.·´ (¸.·¨¯` PWLOVE

You're welcome. Yep this isn't obvious first, but those templates you need to edit rarely, I guess that's why they're hidden by default.

Hi LeiHa and welcome here! Pw is also great to learn some basic PHP, so I'm sure it's the right choice for you. Back to your question. You can add any fields to the User like to other templates in ProcessWire. In fact, Users are also Pages (like everything) and have their own template called "User". In your admin-panel, go to Setup > Templates. Click on "Filters" and show the System Templates. Now you can edit the User-Template and add your custom fields. In your frontend, you output them the same way as other fields. For the current user and the email-field, this would be: echo $user->email;

C'mon be honest and confess that it actually took you 6 minutes

Thanks ryan, I will test soon and report back. @Soma Yeah I'm using this solution on two sites at the moment. But I think the trick with the title is in some situations easier to handle: No checkboxes, I don't forget to add them to a new template. Or if you have the checkboxes global and not every template needs them, that could be confusing too. For the client it's an easy rule: If you don't set a title in language xy, this page won't get displayed. I think its a condition for the title to have a value, otherwise a page is not fully translated and therefore shouldn't output anything.

Just comitted v 1.0.1 to Github: - Added checkboxes for include=hidden, include=all so you no longer need to write those in the selector - Made AdminDataTable sortable - Each status is now in its own column - this means you can also sort the results by status - Added message: number of pages found I initially disabled the sorting on the table because there was an issue with the checkbox in the first <th> which can be used to toggle all the checkboxes. The solution is to disable the sorting of a specific column with jqueryTableSorter: $.tablesorter.defaults.headers = {0:{sorter:false}}; ...where 0 = first column, 1 = second and so on, should anyone else ever need this.

Basic question: Are you sure the user is found? Debug mode on and no error messages?

Thanks ryan, I didn't think of a bug. Your example works fine for other languages than the default. Made it work like this: $langId = ''; if ($user->language->name != 'default') $langId = $user->language->id; $pages->find("title.data{$langId)!=''); Query pages based on empty fields in other languages without this condition would be ultra-sexy

At the moment, the status(es) are displayed when a page is: unpublished, hidden, locked or trashed So for a normal page there's no status. I don't know, does it make sense to display also a status for the complement? Published, not hidden, not locked, not trashed Did you add "include=hidden" or "include=all" to your selector?

You're very welcome Marty! Enjoy your bacon.