OviS

@Robin S Thanks for the fix! working now, but I just found another bug in 0.1.1: the virtual parent stops working if it's the 1st page in the tree (first one under Home). Otherwise, if it's 2nd or more (or "lower" in the display tree) it works perfectly. With a clean setup of PW 3.0.98 and virtual parents, with a structure like this, everything works fine: Home | - Basic Page | - Virtual Parent | - Virtual Child 1 | - Virtual Child 2 But move Virtual Parent to be the 1st child of Home, and Virtual Parent shows no children: Home | - Virtual Parent (no children - no downward arrow, no number of children digit, no expansion on click interaction) | - Basic Page Move it back to be the 2nd, and it works again ? Edit for clarity: the Virtual Parent doesn't have to be manually moved to be the first child of Home, after being configured as the Virtual Parent for this behavior to happen. If the Virtual Parent page is already the 1st child of Home before the config is applied in the Virtual Parents Module, the bug still happens - and one gets the impression that the module doesn't work at all, which was very confusing ?

Just ran across another issue with the module: When active, it seems to be limiting the number of pages displayed in the page tree to 11 children of the Home Page (of which one is the virtual parent). How to reproduce: on a clean install of PW 3.0.98, install and configure Virtual Parents as usual - for example virtual-parent-page=virtual-child-page; create 1 page under Home with the "virtual-parent-page" template ; create some pages under Home that have the "virtual-child-page" template for that Virtual Parent - they will be correctly moved under the Virtual Parent page; create some more pages under Home with "basic-page" template (not configured in Virtual Parents Module), so that they show alongside the Virtual Parent Page in the tree, until you have a total of 11 children of "Home" showing in the tree - so far so good; create 1 more page under Home, with the "basic-page" template, name it something special, like "Important page"; the new page will not appear in the tree. if you turn off virtual folders and manually sort the new page to the top, it will show, but another page will be hidden (the one at the bottom of the tree) when turning Virtual Parents back on. if you keep creating new pages under "Home" they will not be shown in the tree.

@Robin S I finally found out what was breaking your (awesome) module - it was another module, of course, and one of yours too ? Specifically, it was Batcher (https://github.com/Toutouwai/ProcessBatcher) I'm converting a WP website and was using https://github.com/adrianbj/ProcessMigrator and https://github.com/nicoknoll/MigratorWordpress to import the pages from WP. The client insisted to maintain the URL structure of website.com/blog-post-here/ - hence the need for Virtual Parents to keep the page tree tidy. That's where I used Batcher to move the pages from their imported parent to the root of the website. After doing that, Virtual Parents broke. I restored a backup and tried again - this time moving the pages manually and Virtual Parents kept working fine! What I suspect the problem is: When trying to move the imported blog-posts manually, I noticed they were set up to have only one allowed parent - the blog-posts page (also created during the import). So basically, using Batcher, I was able to change the parent of pages to one that was not allowed through their template config. Not 100% that is was what was breaking Virtual Parents, but one definitely shouldn't be able to move pages with Batchers where they're not allowed to live. Thanks for all your great work!

Awesome idea but doesn't work for me (PW 3.0.102). Once configured and activated: all pages but the virtrual parent are hidden from the tree the parent page's name in the tree goes invisible (the number of virtual children does show) when opening the virtual parent to view the children, a copy of the initial tree is rendered, with just the virtual parent shown. this can be done ad infinitum See the image below where I tried to move 64 blog posts into a virtual "Blog" Parent:

Finally figured it out (faceplam moment): a browser extension was messing with CKEditor inline mode and preventing it from saving. There were no errors because the browser extension was not passing it the content I was entering, it was just making it look like it. For the record, the browser extension is Grammarly. I should feel wiser for figuring this out, somehow I don't Thanks to everyone for your help with this!

Yes the CKEditor works perfectly in Regular mode, it's just the Inline mode that's not saving. I just tried it on a fresh install of 3.0.35 - same problem, so like I thought it must be a problem with the server config, I'm just trying to find out what it is. I just tested it in a fresh install of 3.0.35 on yet another host - a shared one with a very reliable server config which I use as a staging server before deployment to production. Same buggy behavior is present. If it's not mod_security - since it's not installed - what could it be? EDIT: if we rule out a PW bug, and we rule out a Server config issue, the only remaining option is a bug with CKEditor itself - but I don't know what in my environment could be causing it.

thanks for pointing me to the Tracy Debugger module, wasn't aware of it, looks like an awesome tool even if I can't use 90% of its features because they're above my knowledge level. The Tracy Debugger shows that it can't detect mod_security as being installed ("mod_security: "). Even though it's not a hard confirmation, it's consistent with what I found snooping around via SSH into the server. Thanks for all the help so far! Any ideas where to go from here?

I don't think mod_security is installed on de dev box, because: apachectl -M | grep --color security returns nothing and apachectl -M returns: core_module (static) so_module (static) watchdog_module (static) http_module (static) log_config_module (static) logio_module (static) version_module (static) unixd_module (static) access_compat_module (shared) alias_module (shared) auth_basic_module (shared) authn_core_module (shared) authn_file_module (shared) authz_core_module (shared) authz_host_module (shared) authz_user_module (shared) autoindex_module (shared) deflate_module (shared) dir_module (shared) env_module (shared) expires_module (shared) filter_module (shared) headers_module (shared) include_module (shared) mime_module (shared) mpm_prefork_module (shared) negotiation_module (shared) php5_module (shared) rewrite_module (shared) setenvif_module (shared) status_module (shared) Also, # ls -l /var/log/apache2/modsec_audit.log ls: cannot access /var/log/apache2/modsec_audit.log: No such file or directory Am I looking in the wrong places?

Thanks, am looking into how to disable it via server config now, will post back with results.

Tried: <IfModule mod_security.c> SecFilterEngine Off SecFilterScanPOST Off </IfModule> in the .htaccess file, but still not working

Hi, I ran into this problem recently and I really need to use inline CKEditor fields on my pages. Steps to reproduce: Download and install the latest version of PW (either 2.8.33 or 2.7.2 behave the same way for me). I used the "Blank" profile when installing. Create a "body" Textarea field and set it to use CKEditor and save it. Add it to the only existing template for the homepage. Switch the "body" field to inline, save it. Edit the homepage by putting anything into the "body" field and saving. Expected behavior at this point: the field should save its contents and show them after the page reloads What actually happens: the field is reverted to its previous state after the page reloads if it had content before (that was inputted when the field was not in inline mode) then it will revert to that content if it had no content, it reverts to being empty. Errors: There are no errors being generated in the PW logs. There are no errors being outputted to the Dev Console. There are no server errors in the log. Environment config Running the latest version of Scotch Box Vagrant: OS: Ubuntu 14.04 LTS Web Server: Apache 2.4.16 PHP: 5.6.14-1+deb.sury.org~trusty+1 PHP Modules: attached in txt file MySQL: 5.5.46-0ubuntu0.14.04.2 I'm thinking this couldn't be happening just for me since it's a very obvious bug, but it's happening on the production servers (apache 2.2 and php 5.5) as well as the dev box. Could it be a server configuration issue? Thanks! php_modules.txt

The solution is here: https://processwire.com/talk/topic/12375-urgent-will-pay-help-debugging-image-fields/

@Macrura thanks for the advice, but we're usinng a managed Cloud VPS server on ServInt. We have full control over the server, and honestly I don't want to switch from using ServInt since they have been an amazing host so far. All server installs and upgrades were done by ServInt MST professionals at my request so I'm sure I haven't messed anything up on that regard. Currently we're running Apache 2.2.31 on CentOS 5, PHP 5.5.30 and MySQL 5.6.23. Thinking of upgrading the OS and then Apache to 2.4.17, seeing if that helps. Also I detected we're actually running a buggy version of iconv, seeing if fixing that might help. As you can see I'm really trying to cover all the bases hunting down for this thing, and I still haven't lost hope (although we are migrating some of our key websites as we speak, unfortunately). Other CMS we've tried running on the server has worked flawlessly. There must be an bug / missconfig somewhere that's being missed I think.

max_input_vars was set to 1000 and post_max_size was set to 100M all along, so this lead is a no go as well.

Just updated to MySQL 5.6.23 from 5.1.73 - problem still persists.

We don't have anywhere near the amount of variables discussed there, but I will definitely look into both post_max_size and max_input_vars. Thank you so much for your suggestion.

Thanks so much for your reply @arjen ! We've been doing it on a number of websites as well, believe me, but some websites get to the point where you can't delete an image to replace it with another, and that's just un-workable. Glad to see I'm not going insane here, was starting to doubt myself . We are on a managed VPS from Servint so we should be able to switch MySQL versions. Thanks so much for the tip! As for migrating - the problem is not only this bug, but the way it's been addressed. We need a reliable way of getting some support if something like this happens in the future. The more websites we make the more support becomes an issue, and if something like this were to affect a large number of our websites and break them then we couldn't afford to wait for 2 weeks and hope for help on the forums. I LOVE the PW community and PW itself, but this is is becoming too big a risk to our business, that's why we're considering migrating (and yes that is a lot of work indeed). Will let you know if I can get to the bottom of this.

Two weeks later and still nothing Sorry but this is ruining our business. I'm biting the bullet and converting all our affected websites to Craft CMS.

Thanks for that Adrian! No, the issue is not tied with the ImageExtra module, I installed that one in an attempt to find a workaround - adding another field to hold the description, but those fields started malfunctioning as well. Most recently it's happened on a website which had the CropImage Module installed, with ProcessWire version 2.3. But the issue is not affecting only CropImage fields, but normal image fields too, which leads me to believe it might be a problem with the core image field, which all of these other fields extend (if I understand correctly how modules work). Upgrading PW and all modules to the latest stable version did not fix things (as I hoped), btw. EDIT: right now I have created a new CroppableImage field and copied all the content for each page into it, but I left the malfunctioning field in place, to provide a subject for analysis. So far the new CropImage field is holding, but it did bug out the first time I was copying the content over about half-way through - and I had to start over again by deleting it and creating a new CropImage field. I learned something that way - if I delete a bugged image field and then re-create it with the same name, the problem persists (the description field still doesn't work) - I had to give the new field another name.

Anyone? Any ideas please?

Update: if i create a new field for an image field using "imageExtra" plugin, the new field works as intended. If I remove and add a field that wasn't working before, that does nothing (it still doesn't work when I re-add it). So the image text fields are somehow getting corrupted after being used in some scenarios. Update2: Also, if i add the image field to another template, it still behaves the same way (not saving description) so the problem is at field level. Update3: I've just noticed another problem: I can't delete images from the image fields exhibiting this bug anymore. I mark them for deletion and save the page - they appear right back after the page reloads.

Nope, not using multi-language at all Might have something to do with deleting images though, that might trigger the bug.

As the title states, this issue is a slippery one, as it doesn't happen immediately when creating and using a field. Problem description: After I create an image, cropImage or croppableImage field (they all share the problem) it works as intended, I can upload, crop and edit the description as I please. After a while (editing a few pages i guess) the description field for each image stops saving, when I save the page, it remains "stuck" to whatever value it had (or empty). Uploading and deleting images still works as normal, just the description field and any other text fields I add via "imageextra" stop working. Steps to reproduce: I don't know what steps to take to reproduce it exactly, but it has been happening with every field I have tried using. So far. Solutions tried I have tried using different image fields, and even using the "imageextra" plugin - nothing helps, they all stop working after a few minutes. I have no errors in the chrome js console, no errors in the PW log. Running "check field data" on the problem fields returns no errors or problems. Configuration: This last issue is on a live website running PW 2.6.1 Master. Server is running Apache 2.2, PHP 5.5. What's worse, this has been happening over the course of the last cople of months on other websites, on the same server, on multiple PW versions. Thanks in advance for any help, if I can't get this to work I will have one angry client

Wow, I thought exactly the opposite, that I had to keep that option checked! Thanks!

I might be missing the obvious here but I can't find anywhere to configure the smartfields as shown in that image. I am using the latest version of the plugin, and the config page doesn't have anything for smartfields. Thanks for the great work!