ryan

Soma I was wondering if you could try out this /index.php file attached and let me know if it fixes it on your end? Since I don't have an example like yours to test from I just wanted to double check before committing. Thanks, Ryan index.php.txt

Okay cool so it looks like realpath fixes it. I'll make the update and commit it. Thanks!

Have you tried it? I think it should work out of the box. At least, I can't think of any reason why it wouldn't. Let me know of any specific areas of concern. The only thing I can think of that may have to be a consideration is the https vs. http settings for each template. If you access a page on an http addr using an https-only template, it will redirect to the same URL but with https. That may not be a problem. But if you find it's creating any issues, you can always leave the template set at the default (which is to accept traffic from both https and http), and then perform your https check in your template using $_SERVER vars.

I just updated my original message, wondering if realpath() fixes it. Not sure it'll tell you my message was updated, so you may have to click back to page 1.

Thanks for sending that. Can you try this in your strap.php and tell me what the output is? <?php include("../index.php"); echo "<pre>"; echo $_SERVER['SCRIPT_FILENAME'] . "\n"; echo __FILE__ . "\n"; Here is the output on mine for instance (two of the same lines): /Applications/MAMP/htdocs/skyuser/test/index.php /Applications/MAMP/htdocs/skyuser/test/index.php I'm guessing yours are different and we may have to use realpath(). So if they are different, try this and let me know if that does it? <?php include("../index.php"); echo "<pre>"; echo realpath($_SERVER['SCRIPT_FILENAME']) . "\n"; echo realpath(__FILE__) . "\n"; Thanks for your help testing this.

Thanks for posting this, it is really helpful for me to see! Hopefully I can duplicate and find a solution.

Something like onkeyup may not be ideal not only because of the overhead but because those events may or may not represent changes (arrow keys being an example). Are you using the ed.isDirty check? My understanding is that is necessary in order to really tell if it changed. Below is quoted from the TinyMCE page on the onchange_callback: Also, make sure that you are just monitoring TinyMCE and not also the textarea separately. If the field is using TinyMCE, you will want your other code to ignore the textarea. These are just ideas and you may have already tried this stuff, but I'll keep thinking here too. TinyMCE is always a hassle no matter what we try to do with it, but thankfully it's always great once things work.

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