ryan

This would be a fine way to go. Since you can't have a checkbox "checked" by default, you would want to use and name/label your field accordingly and use your checkbox to toggle the non-default behavior when checked. ProcessWire doesn't know the difference between navigation and searches. Every API call to ProcessWire is a search, whether you are using it for navigation or not (ProcessWire doesn't know what you are using it for). If "hidden" is checked, then it excludes it from the search, unless you add "include=hidden" or "include=all" to the selector. So if you want a page to be excluded from both navigation and searches, then you would want to make it hidden and avoid having a "include=..." in your selector. There are also other built-in ways to exclude a page from appearing in results from API calls, including the "unpublished" status, and access control.

This sounds like a good solution to me. I can see this being useful. Though I'd probably want to make any relative paths relative to the /site/templates/ dir, just to prevent any ambiguity about the starting point.

Check your javascript error console. There is a 404. Your AJAX is trying to load the URL with a period "." appended to it. I'm guessing you've got an extra period somewhere in your javascript. I'd also suggest adding an extra slash to the end (to avoid an unnecessary 301), unless you've specifically disabled slashes in the template's URLs tab. GET http://webking.gr/web_design/website-web-design-web-development. 404 (Page Not Found) Note the period at the end of the URL above.

The matches() function has actually been moved to be part of the Password value itself, so this is one thing I will add to the 2.3 API docs.

Most of ProcessWire's admin can function without Javascript, but sections of the admin that rely upon asmSelect's sortable functionality require javascript. I think the Template edit screen is the primary one that would be problematic. The PageList should technically be able to function without Javascript (though haven't tried it in awhile), but you lose the ability to drag-sort of course. I'd always intended the admin to be workable without JS, but the demand for it has never come up, so it's not had much focus since version 2.0 was released.

Yet another option would be FieldtypeConcat, where you can combine the output of multiple fields into one, and then use that field as your page list label.

That's true that the complexity requirements aren't configurable at present. Though I could feasibly make it configurable, but this is the first time the request has come up. Currently, the requirements are that the password must have at least 6 characters, one of which must be an ASCII letter of a-z or A-Z, and one of which must be a digit (0-9). These requirements are only enforced interactively, and in the PW admin. So if you populate a password to a user from the API side, like $user->pass = 'something'; there are no requirements. Meaning, you can choose to enforce your own requirements before populating $user->pass with a value.

The CKEditor module is beta, and if you guys any config options that you think we should add to it or anything like that, just let us know.

What's interesting to me is how similar forums like this are to the way BBSs were, at least with regard to the community aspects. Though with many good BBSs, you always had to redial dozens of times before you could make a connection, so you really had to be committed. In my case, I was sometimes spending a couple hundred dollars a month connecting to BBSs in Europe (like Future Crew's Starport BBS in Finland) to download the latest demoscene releases to distribute them in the US. It was a costly hobby.

I do it all the time here. You are right that it's a good idea to make it use a different session name for each. Being logged into one of the PW instances doesn't have you logged into the other, either way. @harmster: you can always disable the CSRF protection too by editing your /site/config.php and adding: $config->protectCSRF = false; That's not an idea solution, as having CSRF protection is a good idea. But it will solve it until you can find another resolution.

Let me know when you think it's stable/ready, as I'd really like to have this built-in to the core. It doesn't seem like there's any real overhead to this, just a very handy tweak to have when you want it. I can see using this quite often. One question: when you are copying/pasting, say from Photoshop, where does the JPEG compression actually take place? Does Chrome compress it as it pastes, or how does that work? Great screencast BTW!

Absolutely! That sounds great. Thanks for getting it working in nginx.

Subdirectory vs. root doesn't matter. Most likely ProcessWire can't get sessions started. Try removing your /site/assets/sessions/ dir completely, and then re-creating it. Give it whatever permissions are necessary for ProcessWire to write to it. If you do 777, and this is not a dedicated server, then check with your systems administrator to see if you can lock that down a little better.

Soma is correct. You need to replace "limit = 10" with "limit=10".

Very cool Diogo! Tested out here and works beautifully. Did a flat copy from Photoshop and went straight into the site. So useful, seems like this belongs in PW's core InputfieldFile.js, if that's alright with you? Because this only affects the JS side, it doesn't seem like there would be any potential security concerns or problems to worry about. A few questions: Do you know how broad browser support is for this? Is there any benefit to making it configurable? (i.e. "do you want to support pasting of images? yes/no"). I'm thinking that would be unnecessary configuration, but just checking. For broader theme support, I'm thinking the text shouldn't be yellow or caps, but just the same as before except with 'paste' linked: "Drag or paste files in here"

Awesome work! One of the coolest PW sites I've seen.

Actually that error message does make sense. Though this might be something that wouldn't behave the same way in all PHP versions. But it's something that should be changed in InputfieldCropImage either way. Starting on line 27 of InputfieldCropImage.module, can you change this: protected function renderItem($pagefile, $id, $n) { $out = parent::renderItem($pagefile, $id, $n); with this: protected function ___renderItem($pagefile, $id, $n) { $out = parent::___renderItem($pagefile, $id, $n); Basically, prepend three underscores "___" to the renderItem definition and call.

I have to admit that I like learning from videos and books. They help to get across bigger picture concepts much better than copying and pasting. They build a foundation. So when it does come time to writing code (or copying pasting it), you've got the understanding of it. The problem with copying/pasting is that it's like building without a foundation, which can be dangerous. When you've got the foundation, all the other pieces just kind of fall into place. I think this is especially true of ProcessWire. If you understand the big picture and how simple it is, the rest of it becomes simple as well. And there's no reason not to learn the foundation, because it's so darn simple. It seems like a lot of people start working with ProcessWire while thinking of it in the context of some other CMS. So there is inevitable "un-learning" that has to take place, as people are looking for complexity where there isn't. This is a recurring theme. What I think would do an even better job of establishing the foundation would be two printable PDF documents that are maximum 1-printed page each: ProcessWire in a nutshell, a cheat-sheet – Covers everything you need to know to understand a typical site profile. Pages, Fields, Templates, then $page, $pages, and PageArray. All you need to know about PHP to use ProcessWire – This one would focus on the general PHP concepts necessary to use it like a template engine with ProcessWire. Covers things like PHP tags, double-vs-single quotes, echo, if(), foreach(), and comparison vs. assignment.

I don't totally understand what that option does, but I've gone ahead and added it. You should see it in the latest commit. So long as you aren't using inline mode, it should allow you to specify the styles? Though to be honest, I don't use these options myself. I like to keep the client thinking about content and not design when in the editor. So displaying the same styles on the front-and-back end is counterproductive towards that.

Not sure what the issue was with GitHub, but their ZIP download URLs have changed a bit. Rather than the filename "master", it is "master.zip". I'm guessing they setup static redirects to ensure that the "master" links would continue working, when they made this change. But that redirect is pointing to PW 2.2.9 rather than 2.3, so thanks for letting me know Peter. I have added ".zip" to the end of the URL and now it seems to be pointing to the right version. Also fixed the GitHub summary text, thanks interrobang.

Thanks u-nikos! I think that nginx support would just be a matter of finding the equivalent rewrite rules. These are a fairly small part of ProCache (only a few rules necessary). So one simple route would be to remove write access to your .htaccess file (so ProCache can't modify it) and then take the rules that it says you should paste, and translate those to the equivalent nginx rules, before pasting them in. I'm not exactly sure what the issue is, but Soma had mentioned that there was an issue. I don't know the inner-workings of the LanguageLocalizedURL module well enough to understand what the issue might be. I've got a few to-do items on my ProCache list before I can focus on the LanguageLocalizedURL issue. But if anyone has the time to experiment with the LanguageLocalizedURL module and ProCache sooner, to see what the issue is, I can attempt to make updates/tweaks per your feedback. Btw, ProCache should work with the new LanguageSupportPageNames module included with the core. I've not actually tested it yet, but don't see any reason why it wouldn't work.

I agree, and I actually have tried to implement this before. I could never get jQuery's double click event register and work here. I suppose it's because we are already using the click event. But if someone else figures out how to get both double click and click working for it, I think it would be worthwhile to have.

Matthew, the primary problem I can see is this line: if(!$contact_photo->getErrors()) { The issue there is that getErrors() always returns an array, which always resolves to "true" in your if statement. In order for it to work properly, you would need to count() the return value of getErrors() rather than typecast it to a boolean like you are doing now. However, I don't think that getErrors() is a good way to check for success with WireUpload, because errors could occur while files were still uploaded. So it's better for your code to ask the question "were any files uploaded?" rather than "did any errors occur?". Then worry more about errors if no files were uploaded. There were also several other minor issues or concerns, but I think the issue mentioned above is the primary reason it wasn't working. I've attempted to re-factor your code and resolve all the issues/concerns that I would have had with it. This is written in the browser, so there may still be typos, but hopefully the intentions are clear: <?php /** * Process the contact form * * Populate's ProcessWire's $notices API var with errors and messages * * @return bool Returns true on success, false on failure. * */ function processContactForm() { $input = wire('input'); $sanitizer = wire('sanitizer'); // Set a temporary upload folder where the files are stored during form processing // RC: precede temp dir with a period to ensure it remains non-web accessible $upload_path = $config->paths->assets . "files/.temp/"; // RC: create temp path if it isn't there already if(!is_dir($upload_path)) { if(!wireMkdir($upload_path)) throw new WireException("No upload path"); } // New wire upload $contact_photo = new WireUpload('contact_photo'); // References name of HTML form field $contact_photo->setMaxFiles(5); $contact_photo->setOverwrite(false); $contact_photo->setDestinationPath($upload_path); $contact_photo->setValidExtensions(array('jpg', 'jpeg', 'png', 'gif')); // execute upload and check for errors $files = $contact_photo->execute(); // RC: use count($files) as your decision whether to proceed not not, rather than getErrors() if(!count($files)) { $contact_photo->error("No files received, so not creating page."); return false; } // Save in the ProcessWire page tree; map submission to the template fields $np = new Page(); // create new page object $np->template = "contact_submission"; $np->parent = "/customer-service/contact-us/contact-submission-listing/"; // RC: for safety, only add user uploaded files to an unpublished page, for later approval // RC: also ensure that using v2.3+, and $config->pagefileSecure=true; in your /site/config.php $np->addStatus(Page::statusUnpublished); // Send all form submissions through ProcessWire sanitization or just map a variable // RC: No need to have intermediate variables, I removed them--populating the $np page instead $np->title = $sanitizer->text($input->post->contactname); $np->name = $np->title; $np->contactname = $sanitizer->text($input->post->contactname); $np->email = $sanitizer->email($input->post->email); $np->comments = $sanitizer->textarea($input->post->comments); // RC: assuming this is a textarea fieldtype $np->save(); // Run photo upload foreach($files as $filename) { $pathname = $upload_path . $filename; $np->contact_photo->add($pathname); $np->message("Added file: $filename"); unlink($pathname); } // save page again $np->save(); return true; } // First, confirm that a submission has been made if($input->post->contactname) { if(processContactForm()) { echo "<h2>Your page was saved!</h2>"; } else { echo "<h2>Sorry things didn't work out!</h2>"; } foreach($notices as $notice) { $class = $notice instanceof NoticeError ? "error" : "message"; echo "<p class='$class'>$notice->text</p>"; } } else { // display contact form }

There really isn't a lot of code involved. But you might find it helpful to look at these files, which is basically what boils it all down: /site/templates/blog.inc - shared functions for finding and rendering posts, comments, and navigation. /site/templates/markup/*.php - view (output) files used by the functions in blog.inc Everything else in the profile calls upon those functions, which is what you would want to do when using the blog profile code in an existing site.

There really is no maximum page capacity. If MODX Evo had a limit on quantity of pages, then I'm guessing they were keeping some reference to all pages in memory at once. We don't do anything like that with pages, so any limits have more to do with the server itself… mysql, disk space, file system. I don't see any reason why you couldn't have millions of pages in ProcessWire. Chuck Forsberg and ZMODEM, good times. The BBS I ran was Data Connection BBS between 1989-1995, and wrote software called DataView for viewing inside ZIP (and ARC, RAR, etc.) archives online. Also wrote a software called Oneliner …kind of like Twitter for BBS times. __ \ | __| | _) | | _` | _| _` | ( _ \ \ \ -_) _| _| | _ \ \ ____/\__,_|\__\__,_| \___\___/_| _|_| _\___\__|\__|_\___/_| _| RENAISSANCE WHQ, FUTURE CREW, LEGEND DESIGN, IGUANA, EMF, PRIME - Node 1: (703) 506-8598 - 16.8k HST DS v.32bis Node 2: (703) 847-0861 - 28.8k HST DS v.34 - Sysop: Ryan Cramer [Iguana/Renaissance] Located in McLean, Virginia, USA Online since 1989 No Lamers (had to say that =)