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.