ryan

Soma, can you try this test: 1. Create a subdirectory off of your PW installation directory, i.e. /test/ 2. Put this file in there: /test/test.php <?php include("../index.php"); echo $wire->pages->get("/some/page/")->url; If your site is installed at root, it should say: /some/page/ If your site is installed in a subdir, it should say: /subdir/some/page/ Are you getting something different? If so, what's the server environment? If you have phpinfo output that you want to PM me a URL to, that's all I would need to see. Also, double check that your /index.php is the latest version from yesterday (which is where this change was made). Very often when people (at least me) update their PW install, they just replace the /wire/ dir and not the /index.php, but this is one case where you'd need to replace the /index.php in order for it to work. Thanks, Ryan

Marty, the possibilities are pretty much limitless here, so this can be structured however you want it. If I'm following your right, it sounds like you want to be able to list the categories in your Portfolio section even though they don't technically live there. That's no problem. Just edit your Portfolio index template, click on the URLs tab and tell it to allow URL segments. Now you can have our Portfolio index template look for categories and display items from them: <?php if($input->urlSegment1 == 'categories') { if($input->urlSegment2) { // example: /categories/work/architects/ // category specified, list items in category: $name = $sanitizer->pageName($input->urlSegment2); $category = $pages->get("/categories/work/$name/"); if($category->id) { // valid category, list items in it echo $page->children("categories=$category")->render(); } else { // unknown category echo "<p>I don't know that category.</p>"; } } else { // list categories echo $pages->get('/categories/work/')->children()->render(); } } else { // list all portfolio items echo $page->children()->render(); }

Here's a little more info about the onchange_callback as well as the isDirty property (I meant to paste this in before): http://www.tinymce.com/wiki.php/Configuration:onchange_callback I doubt that the "live" is adding much overhead, though don't know for sure–but if one() works there that seems better. It was more the "input" event that I thought would be overhead heavy since it triggers on every character you type. I was just wondering if using 'input' (rather than just 'change') is necessary? (it may be, but wanted to check) I'm not sure I understand the current name because 'Check State' can mean a lot of things, and it's handling more than just the PageEdit form? I would probably use something like FormChangeMonitor or FormSaveReminder or something like that? But whatever you think is best. Your current name is certainly better than something like my PageLinkAbstractor module.

Okay I think I've got it fixed. You'll want to grab the latest P21 commit, or if you prefer just the /index.php file from it. Thanks for finding this issue.

I see what you mean. I can duplicate here too. I will work on this and post a fix shortly.

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: