Leaderboard

Yep the problem is the one tpr describes. Beside that, you should consider the following: Don't build your urls manually, let ProcessWire do it for you: $action = $pages->get('/checkout/')->url; <form action="$action"> Sanitize input $id = (int) $input->urlSegment1; // Must be an integer Cache the page you're searching; I'm sure that ProcessWire also returns a cached page, but in theory, each $pages->get() call fires an SQL query: $myPage = $pages->get($id); // Assign the found page to variable $myPage if ($myPage->id) { // Make sure we found a page echo $myPage->title; } Escape output $title = $sanitizer->entities($myPage->title); echo "<input type='text' name='product' value='{$title}'>"; Edit: This is only needed if your title field does not have the "HTML Entitiy Decoder" textformatter applied. Cheers

I found temporary solution and that is in connection with JSON response (because of that uploads stop at ~ 80 - 99 percent and can't finished). Very important part is that I have this problem (in admin/back-end) when debugging mode is switched on: // site/config.php $config->debug = true; Or, if debug mode is off everything works fine - no problem when PW api need to resize uploaded image. But, because debug mode is ON, in JSON response (only there) I have also details: Permission denied in ***\wire\core\Functions.php on line 254 Undefined variable: pathname in ***\wire\core\WireTempDir.php on line 170 Result of that is javascript error (strange JSON response) and "view" part is "incomplete" (progress bar stopped, and image doesn't show). Currently my temporary solution for this (Windows) problem are two simple steps: 1. wire/core/Functions.php, function wireRmdir(), at the end add something what I don't like to use, but it's works - "@" error control operator // wire/core/Functions.php // function wireRmdir() // line 254 return @rmdir($path); 2. wire/core/WireTempDir.php, function remove(), define $pathname // wire/core/WireTempDir.php // function remove() // line below 134 $pathname = ''; Windows, wamp, PW 2.5.29 - debug mode ON - backend - problem to upload images wider than "Max width for uploaded images" Regards, Sasa

Hi, regarding to a BlogPost from @Ryan yesterday, I want share a simple solution for all windows user, but the comments cannot show <?php start tags. So I post my comment here and link to each other. ------------------------------------------------------------------------------------------------------------------------------------- You can mimic this, for example on windows, very easy like this: 1) create a php file, here named "pwphp.php", with this content: <?php echo "PHP (" . phpversion() . ") - Interactive mode enabled\n"; $fp = fopen('php://stdin', 'r'); define('quit', 'quit'); $in = ''; while('quit' != substr($in, 0, 4)) { echo 'php > '; $in = trim(fgets($fp)); eval($in); echo "\n"; } exit(0); . 2) create a windows batch file like this, (here named as pwphp.bat): @ECHO OFF SET phpexe=C:\php-54\php.exe SET phpparams=-d output_buffering=0 TITLE PHP Interactive Mode :: %CD% "%phpexe%" %phpparams% %~dp0pwphp.php TITLE %CD% Drop both files into the same directory. But this directory must be in your systempath! Now open a windows shell and type: pwphp and have fun! To finish and leave Interactive Mode, you type "quit".

FrontendUser The FrontendUser module provides a frontend login, logout and user registration functionality. Features See module documentation for details. login with error handling and value sanitizing Plugin: ProcessForgotPassword core module integration Plugin: LoginPersist module integration user registration with username and email address already in use check email adress pre-register validation (email verification) Extendable with additional fields and by PW hooks forms generated by PW form api Custom style / script Requirements FormHelper (0.7.1+) Usage Documentation / examples Repository PW module repo GIT repo ToDo / Issues Issues I hope it will be helpful to the community and I would be glad to get feedback or suggestions for improvement!

Depends on your use case, but I personally prefer GET variables in cases like search features. This way users can link to search results, share or bookmark them, and so on. What the URLs look like tends to be less important to me, though I do get your point too. Generally speaking GET requests are preferable for "query" type requests, while POST requests have the edge when it comes to requests that trigger changes, shouldn't be cached or stored as-is, etc. This article by Jukka Korpela contains a pretty good summary about the differences, why they matter, and what are the preferred use cases for each method. Anyway, glad you got it working!

Fredi is friendly frontend editor for ProcessWire. Code and documentation: https://github.com/apeisa/Fredi Module page: http://modules.processwire.com/modules/fredi/

This is a topic I check out every now and again because, especially on photo-heavy websites, some "seamless" way of resizing images before they are uploaded is something I've always wanted. You know the scenario - someone shoots a bunch of images with their 21 megapixel camera, tries to upload them not thinking about file sizes and the page hangs for ages whilst the image is resized. Or, worse, it times out because you didn't give PHP enough memory or increase the max execution time. I've tried a few PC-based tools to make like easier for clients - some in Windows are part of the right-click menu even, so they just need to remember to right-click and resize. But wouldn't it be nice to have something that does it automatically? Well this might just be the answer: https://github.com/blueimp/jQuery-File-Upload/wiki/Client-side-Image-Resizing - which is part of a larger library: https://github.com/blueimp/jQuery-File-Upload My question, because I just don't have time right now (lame excuse, but I've got a lot on and this may be of interest to you guys anyway), is whether anyone else has tried this particular set of scripts out, or if the image manipulation gurus amongst us (I'm looking at you Horst ) have considered something like this (canvas to blob conversion on-the-fly before upload seems to be what's happening here) or whether something like that seems simply too volatile - I imagine on huge images it could consume a lot of memory on the person's PC, which is still quicker as a smaller file is uploaded, but may have other side-effects. I have used a Java applet in the past primarily to handle huge files, but that also had some client-side image manipulation built-in, but Java is such a security issue nowadays it's unbelievable. Plus it requires Java to be installed in the first place, so something JavaScript-based, using browser features like canvas if they're available seems ideal, with fallback to simply uploading the large file and letting the server resize the image. One to think about anyway. I'm sure the W3C will eventually roll out a recommendation for browser-side manipulation, but as we know update and implementations are always guaranteed to come quickly or work consistently.

You're invoking the function with a single argument of the type "string" and the value "690,425", but size() needs two arguments/values, best of the type int. You cannot fake the comma between function arguments. list($w, $h) = explode(",", $size, 2); $w = (int) $w; $h = (int) $h; $slideimage = $slideimage->size($w, $h);

Haven't tried it and can't provide any real expertise here (sorry!) but the problem is quite familiar. If this solution (or something similar) works, and if we could benefit from it right within ProcessWire's Admin, I'd be very, very happy "ecause you didn't give PHP enough memory or increase the max execution time" tends to be the problem with server-side solutions. There's always finite amount of memory, and vastly increasing memory limits in order to account for some specific memory-intensive tasks means that one can no longer count on the memory limit as a safety mechanism.. and that is just asking for trouble. Same thing goes for max execution time.

If you need this to work without get variables you need to build a own way to store the $q vars between pageloads. The simplest way, that does not involve javascript stuff to happen, is storing the variable in the session of the user. From there you can retrieve it as needed before doing your pages search. Edit: Now I know again, why I never used whitelist for that job

Added new FrontendUser module

Isn't your checkout page end with a slash? (yoursite.com/checkout/) If so, you may have a redirect so post values are lost (checkout -> checkout/), so you need to append a slash to the form action. Check it on the Dev Tools/Firebug Network tab.

FrontendUser module handles login, logout and user registration. I moved the complex email validation plugin, ProcessForgotPassword and LoginPersist module integration into the FrontendUser module for testing. If anyone would do some tests... Repo: https://bitbucket.org/pwFoo/frontenduser/overview Doku: https://bitbucket.org/pwFoo/frontenduser/wiki/Documentation Current download for testing: https://bitbucket.org/pwFoo/frontenduser/get/master.zip

I've done a site for a big german company. Unfortunately I'm not allowed to say which one. But... they were unsure if ProcessWire will be the right decision. After showing them the scyscrapers example the felt in love with ProcessWire. Maybe it helps to describe the unlimited possibilities which can easily built with ProcessWire.

You could have a pagefield "notifications" in the users template, and create the notifications as pages connected to the topic (not one per user, just one per notification, that could be used for many users), than you would link the user to the notification, and delete it from the pagefield as soon as it is presented to him. Does this make sense? PS: I know you asked how to not create pages, but I think this way would at least make them much less, and easier to delete when not needed. -- A little pseudo-code for the above: foreach ($user->notifications as $not) { echo $not->body; // show the notification $page->of(false); $user->notifications->remove($not); // remove it from the list if ( !$pages->get("template=user,notifications={$not}") ) $not->delete(); // if there are no more users to be notified, delete the page } $page->save("notifications"); //save the field with the notifications removed

A bit off the topic, but I had to say something ftp, sftp, rsync, git.. Whatever, deployment is as easy simple as we make it. This article kept me cool: http://lesjames.com/deployment/ Btw: Currently, I use gulp, git, hooks (and maybe flightplan in near future) to deliver my stuff. PS: I tried both them all. Notepad, dreamweaver, nvu, pspad, notepad++, bbedit, aptana, netbeans, eclipse, textmate, scriptly, coda, atom, brackets... (Sorted by first use) I'll stay with sublime text... Atom looks pretty neat, but it feels like an early bird, at midnight. And brackets, yeah, it's a toy (today), nothing for productivity, sorry adobe...

Config was just fine. Tested it once again and it works. Maybe typo with the username ?! Sender address of ProcessForgotPassword is overwritten by WireMailSmtp if different, but works fine... Sorry, should be my bad

@pwired: Please share a link to your forum guide. I've found it once, when I was for doing something similar, but never again)) What's the use of forum guide if it can't be found itself )) Seems like everybody's going for some .pw sites now. Why don't you start something like pwforumguide.pw? It might be easier to contribute to than those snippets ones, as you only have to share a link in a carefully constructed tag or category structure. I personally would use it, because I seem to never find the right forum post when I need it. I just know that "the truth is out there".

Good points. The #1 idea sounds interesting and I like where you are going with that, though I don't think it's safe to consider the meta data independent from the content to the point where it would be safe to version them separately. The recorder modes (#2 & #3) would be great if it weren't for the issue of primary keys you mentioned, but maybe there are places where it could still work. I think that anything that involves merging two versions of the same site has to treat the other's data as totally foreign. Things like IDs have to be thrown out unless you are giving all ID generation authority to one or the other. Personally, I have never seen this as a particular problem to be solved because I've never seen the ability to do it, never expected to be able to, and not sure I could ever trust it if it existed. Nevertheless, I'm enthusiastic about exploring the possibility. But I'd be scared to death of having to provide support for such a feature. Something that I've got a higher comfort level with are specific import/export tools. For instance, a tool that enables me to connect my PW install with another, and browse the fields, templates and pages. Then I can click on "import" and have that field, template or page(s) created on my system too. If there's some matter of meta data to be resolved (like a new page reference with non-existing parent), then I know it then and there and can adjust my import sequence accordingly. If I'm modifying data rather than importing, then I can have the opportunity to see and confirm what's going to happen before it takes place. If we're talking about going between two servers that can't talk to each other, then copy/paste of JSON data from one to the other in the developer's browser is another way to accomplish it. This process seems more supportable because the individual site developer still has some ownership over what's happening.