ryan

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 =)

There's really not much to it, it's nice and simple. This article is a great intro to Composer: http://blog.fortrabbit.com/handle-your-dependencies-with-php-composer/

Once the multi-language page names module is stable and in production use. So will probably start developing the namespaces stuff in May. Namespaces are the primary aim, with PSR-0 being a natural extension of that. I plan to shoot for PSR-1 too if it looks like it'll benefit our audience. Also as a natural extension to these updates, I am interested in supporting Composer, and will do so if possible. I agree it's a great asset for PHP, though am less certain if it's as much of a draw for ProcessWire's primary audience. Throughout all of these 2.4 updates, I feel a lot of care will have to be taken to balance these updates with other improvements to the system. After all, our audience is primarily web designers and developers, and less purely PHP coders. I think a majority of our users doesn't actually care about namespaces, PSR standards and Composer, so I don't want to get too far off track, even if I personally have a strong desire for these things. But the driving aim of 2.4 is to help ProcessWire benefit from PHP 5.3+ as much as possible. This likely includes all of the things outlined. I've always been interested in this. PW started as just the content framework, and underneath it still is. I'd like to retain and reinforce those roots. But don't think I want to actively maintain PW as two projects until there is real need for it (just as a matter of resources). I'd like to make it easy for people to integrate components if they want to, and I think Composer is probably the way to do that. But don't currently see a need for any of our core components to come from another framework. Though I'm always open to the idea if there is a real benefit to our users. IoC is not a new concept. ProcessWire was written with an emphasis on best practices, patterns and concepts like this, everywhere beneficial to the project goals. The primary need for unit tests in PW has been with the selector engine, both DB and in-memory, and the consistency of the two. Luckily this is an active project, and it has already been hugely helpful and influential in ProcessWire 2.3 (thanks to Nik). In fact, I would probably consider the issues discovered and resulting solutions the most important upgrade to come with ProcessWire 2.3.

You probably already know this, but you can also specify a path to your own "contents.css" file. It's basically the same as in TinyMCE, where you would want to copy out the default copy and place it somewhere in your /site/ structure, and then modify it to suit your needs.

In addition to what Nik mentioned, I would see if you can narrow down where the bottleneck is. Add the following to the beginning of each function: $timer = Debug::timer(); And add the following to the end of each function: echo "<p>" . __FUNCTION__ . " with page $category->path executed in " . Debug::timer($timer) . " seconds.</p>"; That might help to narrow it down. But if these function calls really are generating navigation with 400+ items, I probably wouldn't expect it to be lightning fast. It would be a good candidate for using MarkupCache. To use MarkupCache, replace all your "echo string" lines in the function with "$out .= string", so that you are populating a variable with the output rather than echoing it. Ideally your functions return the output so that the caller can do the echo, but you could also just put your echo at the bottom of the function. Once you've done that, you can use MarkupCache by putting this at the top of your function: $seconds = 86400; // 1 day, or 3600=1 hour $cache = wire('modules')->get('MarkupCache'); $out = $cache->get("homeHeader($category)", $seconds); if($out) return $out; // or echo $out; // ...the rest of your function code... $cache->save($out); return $out; // or echo $out;

Actually it has support now, and it's there in 2.3. But it's considered "beta", so I don't recommend using it on production sites until I'm at least using it on a production site (which should be about a month from now). But I think it's perfectly fine to go ahead and work with it now for testing and/or development.

In this case, you'd probably have the reverse the logic of the addable() hook. You'd give them the template access. But your addable() and editable() hooks would take it away. That's one approach you could take anyway... But if the blank templates list was the only issue before, you might just want to edit that /wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module file and prepend the getAllowedTemplates() function with 3 underscores, renaming it to: ___getAllowedTemplates(). Then it becomes hookable, and you can modify the value that it returns from your module. Currently in your case, it's returning nothing (since they have no edit access on the template). So you'd want to make your hook modify the return value to include the templates you want them to be able to select from. If you find this worthwhile, let me know and I will update the core to have that function hookable.

I think that some kind of aggregate fieldtype that encompasses others would be a fine way to go. I don't see it as something I would personally use all that often, but I can understand why others might find it useful–it's a worthwhile idea. From the implementation side, a single item repeater probably would be the quickest/simplest way to implement such a type of grouping. But there are some significant differences to the point where it may be better off as it's own fieldtype, perhaps that extends FieldtypeRepeater. Either that, or something new that just takes a similar approach. After all, an aggregate field wouldn't need but 1 "ready page", it wouldn't need a repeater parent page, and could be built around the Fieldtype class interface rather than the FieldtypeMulti interface. It would have less overhead than repeaters would in some areas. There are surely even more efficient ways it could be built, but the repeater-model approach would be the most likely way to make it something tangible in a shorter period. I'll keep marinating on it here.