ryan

That looks to be a really nice file manager they've built there (elFinder), thanks for the link. Perhaps something that could be a nice 3rd party module option to integrate in the future. PW itself is kind of a virtual file system where any given page can act as a directory, so it's very easy to create a structure of pages for storing assets like images for insertion with TinyMCE or the like. But it is true that it's not going to go pull up images outside of PW's file system, so there may be value in having a module like elFinder for some users.

You can also do wire('input'). Same result, but in a function instead. The advantage of the function is that you can call it anywhere and $wire doesn't have to be in scope.

Is your site running off a subdirectory called /process/ ?

I think that the way you are doing it is fine. The only reason it's not working with Template and Field edit is because those are a little different from PageEdit in that one process (ProcessTemplate and ProcessField) handles all the listing and editing functions. Whereas Page's are broader in scope, so the listing and editing are broken out into different Processes. As a result, the 'execute' function on both ProcessTemplate and ProcessField is being used to handle the 'list' action. For either one of those, you actually want to hook into the 'executeEdit' function rather than 'execute'.

Hi Soma. Looking great, just got a change to try it out and seems to work nicely … and very useful too! A few comments: 1. Rather than including a separately copy of InputfieldTinyMCE.js, I recommend adding this to your PageEditCheckState.js (in your ready handler): var TinyMCE_change = function(ed) { if(ed.isDirty) { // the data changed addCheck(); } }; // modify PW's JS config data for each TinyMCE instance $(".InputfieldTinyMCE textarea").each(function() { config[this.id].onchange_callback = TinyMCE_change; }); 2. May not be entirely necessary, but you may be able to confine your input checks to those in an Inputfields form, just to keep it out of any other forms that might be on the page (like search engine, etc.): $('input,textarea,select', 'form > ul.Inputfields').live('input change',function() { or $('input,textarea,select,form', 'form#ProcessPageEdit').live('input change',function() { 3. It looks like your callbacks are getting called on every character pressed. Just wondering about overhead of doing this. Why not just do the 'change' event for text/textarea fields?

Just tried it out, looks great and works great! Thanks Soma!

I will keep trying here. If you come across any other details that might help me to reproduce it, just let me know. Or if you have easy access to record a quick screen capture, that might help to see it. I have a feeling it's an easy fix, but just need to understand it and reproduce it myself.

It does look interesting–good find. I couldn't get their demo to work (in the latest Chrome, other than the nav bar at the top), but am curious about it. Have you tried it out or had any luck getting it to work?

The problem is that you are referencing $_POST directly, and your PHP must have magic_quotes enabled. Your best bet is to use the $input->post var that ProcessWire provides, rather than $_POST, because PW checks for things like magic_quotes and accounts for them. Here is your example modified to use the $input->post rather than $_POST. $wallmessage->message = $wire->sanitizer->textarea($input->post->wall); For post vars that you are going to typecast as integers or the like, it doesn't really matter whether you use $_POST or $input->post. But for anything with text in it, use $input->post because you won't have to worry about whether the PHP install has magic_quotes turned on. The $input var also provides the same for GET and COOKIE vars as well, in addition to some other handy features. Here is more about it: http://processwire.com/api/variables/input/

Sevarf2, I don't think I understand. Can you post what the expected output is in addition to the output you are getting? Or if you have a live link I can click on to see what it's doing, even better.

Wow that was fast. Thanks for the update. I can't wait till I get back to the office Monday to try out these new modules.

Sounds cool, I look forward to checking this one out. We will get something setup in the core for the type of monitoring that you need so that you don't have to bundle the InputfieldTinyMCE.js if you don't want to.

Testing some things out today and see that somehow I messed up the Fancybox initialization on new images uploaded to a field that doesn't already have them (though works for new images uploaded to a field that already has them). Antti you may have fixed this in your update. But when I got your last update, I had already implemented fixes for the sorting and fancybox (or thought I did ), so ended up just copy-and-pasting over the client-side validation stuff you had added instead. My mistake, and a minor problem that I doubt will be noticed, but I will fix on Monday. Just wanted to explain in case you were wondering why the code had changed. Luckily all good with the sorting. Soma, I'm working off my 13" MBP right now and trying to duplicate the issue you'd mentioned with the TinyMCE image dialog. Still can't duplicate. What are the dimensions of the image you are working with? Maybe if you can tell me the dimensions and I can create one the same size (or if you just want to attach the image) that might help me to reproduce it? Thanks, Ryan

If you get this error message: That means that ProcessWire is in production mode (as it is by default) and is not reporting errors as a security best practice. However, if you are just installing ProcessWire or developing a site in it, this error message is hardly helpful. Here are three ways you can find out what error occurred: Look at the last line in the file /site/assets/logs/errors.txt. You have to examine this file directly on your file system as PW makes this file non-web accessible. If you entered your email address for the admin user account when you installed ProcessWire, it will email the fatal error message to you. Though if you are running PW on a machine that doesn't send email, that may not help. Edit the file /site/config.php and change the line that says $config->debug = false; to: $config->debug = true; That will force PW to output it's error messages rather than saying "Unable to complete this request due to an error." Note however that you do not want "debug" turned on with a production site, as it's not good security to reveal technical details like this to users of your site. Any one of the above 3 methods will reveal exactly what error occurred. Regardless of where you found it, the error message will include the following in this order (each separated by a colon ':') Date and time that the error occurred Current user when the error occurred URL of the page that was being viewed Detailed error message with PHP file, line number and sometimes a debug backtrace Most often, examining the information above will make it clear what the problem is. However, if it doesn't, post your error message here (being careful not to reveal any personal server details). Or if you prefer, private-message it to me or email it to me at http://ryancramer.com/contact/. Hope this helps a few people. I noticed repeat instances of "Unable to complete this request due to an error" in our Google Analytics, so it's clear some are experiencing this message and arriving at our site. I wanted to make sure we had a proper answer.

Soma I tested out here–nice job and congrats on your first second module! Just a few suggestions: 1. It's not safe to assume that PW admin is at /processwire/. For instance, the one I tested in is at /mysite/processwire/ (off a subdirectory), and someone else's might be at /admin/ or /my-private-url/ or something like that. As a result, you'll want to replace this: <a href='/processwire/setup/field/edit?id={$id} ... with this: <a href='{$this->config->urls->admin}setup/field/edit?id={$id} ... And likewise with the templates one. 2. I'm getting double field links with Page reference fields. This is because Inputfield::render actually gets called twice for a Page reference. It's a little different than the other fields since it lets you delegate the input to another Inputfield (like select, select multiple, checkboxes, radios, etc.). So InputfieldPage::render gets called first, and then the delegate Inputfield gets called second. The result is two of your links appear. As a result, I would suggest preventing this by either keeping a list of field names you've already populated, or just checking if your markup already appears in the output, like: if(strpos($event->return, 'fieldEditLink')) return; 3. With hooks that get called multiple times, it's more efficient to move the if() before you add the hook, rather than have it within the hook. Or to word it differently, move this: if($this->process == 'ProcessPageEdit' && $this->user->hasRole('superuser')){ …out of addShortcutLinks(), and into init(). The only problem is that init() gets called before the page is even loaded, so you can't determine if($page->process == 'ProcessPageEdit') yet. However, you can do this: <?php public function init() { if(strpos($_SERVER['REQUEST_URI'], $this->config->urls->admin . 'page/edit/?id=') !== false && $this->user->hasRole('superuser')){ // add stylesheets $this->config->styles->add($this->config->urls->HelperFieldLinks . "HelperFieldLinks.css"); // add a hook after each inputfield is rendered and modify the output $this->addHookAfter('Inputfield::render', $this, 'addShortcutLinks'); } } The advantage of the approach above is that it significantly reduces the number of times your hook is called when it's not needed. There's nothing technically wrong with the way you were doing it before either, so I'm just mentioning this as an efficiency optimization. Lastly, and perhaps more importantly, move your stylesheet loader into that if() statement as well (like in the code example above). No need to have your stylesheet loading when it's not going to be used.

Safari is just supporting the multiple='multiple' attribute. Safari lets you drag files from your computer directly onto the 'Choose File' (aka 'Browse') button and it populates the filenames there. But as far as I know, that has nothing to do with the File API. I think it's just one of those things that Safari has always done. I hadn't originally thought that Safari wouldn't support the File API... I always figured Chrome and Safari were mostly identical in rendering and function since they are both using the same engine and version (Webkit). Though I guess I shouldn't be surprised since I avoid Safari and love using Chrome (almost as much as Firefox). Too many spinning beach balls in Safari.

Sometime after 2.1 I'm hoping to find a way that we can select multiple pages at once in the PageList, and then drag-move, or edit them as a group. As for editing groups: if you had multiple pages selected and clicked "edit" it would take you to a PageEditMultiple process rather than a PageEdit process. And PageEditMultiple would be limited to just some of the basics that are on the current PageEdit settings tab ('status' being the obvious one). In terms of selection, if it's possible, I'd like to use the standard shift-click to select linear groups, and ctrl-click to select individually, as well as click-n-drag a box around the group of pages you want to select. I think all these actions would be a natural fit in the current PageList, so it's just a matter of figuring out the code to make it happen.

Nice module Soma, and great (useful!) idea. I look forward to trying this one out later today.

Thanks Pete. Sorry somehow I missed this message before. Large/long projects have their own set of challenges too... like: the client's team changing halfway through, higher risks of scope creep, and so on. It's hard to do more than 1 or 2 a year. The smaller projects end up being more fun and less risky on consistent income. But I think any of us that work independently with a lot of clients always value the opportunity to really focus on something for more than a couple weeks. Big projects leave you satisfied... at least until the client starts designing their own in-house graphics and plastering them on the site.

I've got a MBP 13" too, so will test from there and hopefully duplicate it. Just uploaded a video of the new Ajax uploading in action:

Soma, thanks for the testing. I keep trying to duplicate in Chrome/OS X but so far no luck. What version do you have? I'm running 13.0.782.112 Also, have you restarted Chrome recently (just in case)? Antti, thanks for the updates! I have applied them and added a few last minute details and have committed this feature to the 2.1 source!

This was a 2.0 leftover. Just fixed and committed. Not keeping a separate permission for searching anymore, so now it's active as long as you have page-edit permission. The word "about" is a MySQL stopword. A word too common to index. In the latest commit I added an option to use the 'contains LIKE' operator in the advanced search options. It's slow, but it will find stopwords... so a tool that is there if you ever need it. Use the 'advanced' box and the 'sort by' option to sort. These weren't intended to be sortable from the table headers and it just picked that up from the default behavior of the MarkupAdminDataTable. I've updated it so that they no longer appear sortable in the latest commit. Thanks, Ryan

Good idea Pete. I also really like the example shown here, particularly if the list items can then be drag-sorted. Might have to put this on the list of new Inputfields to add.

I think I understand. I should say though that PW's fields and inputs are designed for administrative use rather than front end use. If I'm building something for the front end, I might still use PW pages to store the data, but I'm handling the input on my own and populating fields into page objects. That's what I recommend because you'll be able to do whatever you want without limitation and use PW's API in the manner it was built for. But if the Inputfields are suiting your need, then here's what you'd do to extend all of them. In the example, we add a hook to the field rendering (to add a select box with each one) and another hook to the input processing. This example module should be pasted into a file called /site/modules/InputfieldHookTest.module <?php class InputfieldHookTest extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Inputfield Hook Test', 'version' => 100, 'summary' => 'Just a test.', 'singular' => true, 'autoload' => true, ); } public function init() { $this->addHookAfter('Inputfield::render', $this, 'render'); $this->addHookAfter('Inputfield::processInput', $this, 'processInput'); } public function render(HookEvent $event) { $inputfield = $event->object; // optional, but better to limit to those you want if(!$inputfield instanceof InputfieldText && !$inputfield instanceof InputfieldTextarea) return; $name = $inputfield->name; $event->return .= "<p><select name='test_$name'><option></option><option>test</option><option>test2</option></select></p>"; } public function processInput(HookEvent $event) { $inputfield = $event->object; $name = $inputfield->name; $post = $event->arguments[0]; $value = $post["test_$name"]; if($value) $this->message("You selected '$value' for '$name'"); } }

Soma, thanks for your testing here. Both are the same issue. I just need to re-apply the fancybox initialization to new images, and have the sort be able to initialize after document.ready(), so it should be a straightforward solution. Just a matter of applying these initializations after rather than before, and do so more selectively. I like the convenience of the AjaxUploads, but dynamically saving sorts is an entirely different thing. It may be okay forms without a save/submit button. But in our context I think it would be an overuse of ajax. I want to be cautious about blurring the lines too much about when something is saved and when it isn't. When people are changing anything on a page, they need to save it. Ajax uploads do create some blur, but it's a progressive enhancement and worth the compromise. I wouldn't want to blur that further. Making it save the page every time you dragged to sort a file would create an expectation that multi-choice fieldtypes (like with asmSelect) should do the same thing, and the template editor, and so on. You wouldn't know when you needed to save and when you didn't. I don't want people to assume that their changes are committed until they've saved the page. One should be able to experiment with different sorts without their experiments being visible to the public. I got nailed by this same problem recently when a site was saving the state of every image I dragged (unknown to me). I never hit save, nor was I intending to. My cat ended up as my profile picture for several days before I realized it! When selecting images in TinyMCE (after clicking the image icon) it shows all the images on the page and limits their width to the window size of the modal dialog. Let me know if you are getting a horizontal scrollbar, as that would indicate it's not working. I don't often deal with images as large as you (you mentioned 6mb), but one option is that I could have the image selection specify a max width that's smaller, like 50% window size or something like that. But this is one place where I lean towards scaling over resizing. For image fields that have automatic thumbnails turned on, it may be possible for it to use those though. As for the image disappearing after you selected it, I'm not sure what's going on there so need more info– does it do that too all images, or just the big ones? I can't duplicate here in my testing (also Chrome latest in OS X), but I don't have any 6mb images either.