• Content count

  • Joined

  • Last visited

Community Reputation

9 Neutral

About OviS

  • Rank
    Jr. Member

Profile Information

  • Gender
  1. OviS

    @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!
  2. OviS

    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:
  3. OviS

    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!
  4. OviS

    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.
  5. OviS

    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?
  6. OviS

    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?
  7. OviS

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

    Tried: <IfModule mod_security.c> SecFilterEngine Off SecFilterScanPOST Off </IfModule> in the .htaccess file, but still not working
  9. 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
  10. The solution is here: https://processwire.com/talk/topic/12375-urgent-will-pay-help-debugging-image-fields/
  11. @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.
  12. 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.
  13. Just updated to MySQL 5.6.23 from 5.1.73 - problem still persists.
  14. 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.
  15. 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.