Ivan Stefanov

@sammiller63, static caching of javascripts, css and images is enabled by default at SiteGround. You can either turn it of through your cPanel -> SuperCacher -> Static Cache tab or Flush the cache from the button in the same feature, which should resolve the issue and allow you to see your changes live.

@sprobot, due to the way how the Staging software is working at the moment, when there are plugins/themes that heavily rely on the WordPress siteurl and home settings from the options table, the best course of action is to temporary add:

define('WP_HOME','https://staging1.example.com');
define('WP_SITEURL','https://staging1.example.com');

into the wp-config.php file of the staging file. Keep in mind that if you push the staging site to live, you will need to verify that aforementioned lines are removed from the wp-config.php file of the live site.

@fjalestad, indeed there seems to be a memory leak most probably caused by incompatibility between PHP 7.x and the theme you’re using right now. As far as I could see, the information in your support ticket is detailed and allows you to pinpoint the exact problem.

As a side note, your staging site is being password protection and this might be the reason WordFence to be unable to reach it at some point.

Hi @fjalestad,

I’m part of the Senior Technical Support team at SiteGround. Can you please provide me with the ticket ID related to the issue, I might also be able to help you with some useful information about the problem:)

@jeherve, can we change the status of this thread as “[Resolved]” flag might be misleading. Thank you!

@greisondias, the issue is most probably caused by the activated server caching mechanisms. In SiteGround, we received couple of similar complaints by users that setup Google Pagespeed as a caching for their websites. Please try to flush the cache and check if the issue will be resolved.

@jeherve, we will be very thankful if you are able to join into this conversation as it appeared that Jetpack is experiencing compatibility issues (or at least with the default opcache settings) when setup to work with PHP 7.1.

This issue was reproduced on a plain WP install as well as on the @zomidaily site, too.

Here is the strace of my personal site:

6851 14716 unlink("/home/ivanstef/.opcache/89683bd16d8b1548698d49eab705558a/home/ivanstef/public_html/wpphp71/wp-content/plugins/jetpack/modules/related-posts/jetpack-related-post     s.php.bin") = 0
6852 14716 stat("/home/ivanstef/public_html/wpphp71/wp-content/plugins/jetpack/modules/related-posts/jetpack-related-posts.php", {st_mode=S_IFREG|0644, st_size=42917, ...}) = 0
6853 14716 mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4eb0800000
6854 14716 munmap(0x7f4eb0800000, 2097152)   = 0
6855 14716 fcntl(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=1}) = 0
6856 14716 fcntl(3, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=0, len=1}) = 0
6857 14716 mkdir("/home/ivanstef/.opcache", 0700) = -1 EEXIST (File exists)
6858 14716 mkdir("/home/ivanstef/.opcache/89683bd16d8b1548698d49eab705558a", 0700) = -1 EEXIST (File exists)
6859 14716 mkdir("/home/ivanstef/.opcache/89683bd16d8b1548698d49eab705558a/home", 0700) = -1 EEXIST (File exists)
6860 14716 mkdir("/home/ivanstef/.opcache/89683bd16d8b1548698d49eab705558a/home/ivanstef", 0700) = -1 EEXIST (File exists)
6861 14716 mkdir("/home/ivanstef/.opcache/89683bd16d8b1548698d49eab705558a/home/ivanstef/public_html", 0700) = -1 EEXIST (File exists)
6862 14716 mkdir("/home/ivanstef/.opcache/89683bd16d8b1548698d49eab705558a/home/ivanstef/public_html/wpphp71", 0700) = -1 EEXIST (File exists)
6863 14716 mkdir("/home/ivanstef/.opcache/89683bd16d8b1548698d49eab705558a/home/ivanstef/public_html/wpphp71/wp-content", 0700) = -1 EEXIST (File exists)
6864 14716 mkdir("/home/ivanstef/.opcache/89683bd16d8b1548698d49eab705558a/home/ivanstef/public_html/wpphp71/wp-content/plugins", 0700) = -1 EEXIST (File exists)
6865 14716 mkdir("/home/ivanstef/.opcache/89683bd16d8b1548698d49eab705558a/home/ivanstef/public_html/wpphp71/wp-content/plugins/jetpack", 0700) = -1 EEXIST (File exists)
6866 14716 mkdir("/home/ivanstef/.opcache/89683bd16d8b1548698d49eab705558a/home/ivanstef/public_html/wpphp71/wp-content/plugins/jetpack/modules", 0700) = -1 EEXIST (File exists)
6867 14716 mkdir("/home/ivanstef/.opcache/89683bd16d8b1548698d49eab705558a/home/ivanstef/public_html/wpphp71/wp-content/plugins/jetpack/modules/related-posts", 0700) = -1 EEXIST (     File exists)
6868 14716 open("/home/ivanstef/.opcache/89683bd16d8b1548698d49eab705558a/home/ivanstef/public_html/wpphp71/wp-content/plugins/jetpack/modules/related-posts/jetpack-related-posts.     php.bin", O_RDWR|O_CREAT|O_EXCL, 0600) = 6
6869 14716 flock(6, LOCK_EX)                 = 0
6870 14716 --- SIGSEGV (Segmentation fault) @ 0 (0) ---

If we can be of any further assistance regarding this matter, you can directly contact me at [email protected]

@ridestoke, thank you for the cooperation! I managed to determine the exact culprit for your issue, which isn’t by any means related to the Jetpack compatibility with PHP7 as I suspected, and your support ticket at SiteGround was updated with more info.

@ridestoke, my name is Ivan Stefanov and I’m one of Senior Technical Support Engineers at SiteGround. Could you please share your Ticket ID and I’ll check your conversation with my colleagues further and investigate the case thoroughly one more time.

I’m also using Jetpack with PHP7 for my personal website on SiteGround and that’s why I guarantee you that with a plain WordPress installation + Jetpack + PHP7 there isn’t any issues.

Looking forward to you reply!

@nosilver4u, thank you for the detailed info. I noticed that binaries are running in 32-bit mode by checking the system calls here:

execve("ewww/jpegtran", ["ewww/jpegtran", "-v", "plugins/ewww-image-optimizer/images/sample.jpg"], [/* 28 vars */]) = 0
[ Process PID=32012 runs in 32 bit mode. ]

and then we managed to identify the issue. In this case there was a kernel patch which disabled the keyctl syscall functionality. This has already been resolved and the plugin is running just fine ??

@nosilver4u, we spotted pretty much the same issue on x86_64 CentOS release 6.7.

Here is the ewww debug result: https://pastebin.com/b080azGn

We’ve tried the work-around by copying the binaries in ~/wp-content/ewww/, but still optipng and gifsicle are reported as missing:

user@serv01 [~/public_html/sgtest]# ls -lagh wp-content/ewww/
total 3.3M
drwxr-xr-x 2 user 4.0K Oct 21 04:18 ./
drwxr-xr-x 7 user 4.0K Oct 21 04:17 ../
-rwxr-xr-x 1 user 465K Oct 21 04:18 cwebp*
-rwxr-xr-x 1 user 353K Oct 21 04:18 cwebp-alt*
-rwxr-xr-x 1 user 733K Oct 21 04:17 gifsicle*
-rwxr-xr-x 1 user 118K Oct 21 04:18 jpegtran*
-rwxr-xr-x 1 user 100K Oct 21 04:18 jpegtran-alt*
-rwxr-xr-x 1 user 726K Oct 21 04:17 optipng*
-rwxr-xr-x 1 user 817K Oct 21 04:17 pngquant*

Could you please check this out?

Thank you!

@clemmo21 I will personally check and address the case. You should have results within the day – please refer to your support ticket.

@rejmark I’ve updated your support ticket on your behalf and escalated it to the attention of our supervisors, where the case will be reviewed further and hopefully the culprit of the issue identified and resolved soon.

@rejmark my name is Ivan Stefanov and I’m one of SiteGround Senior Support Supervisors. Could you please share with me the ticket ID, so we can check the issue on our end further.

Thank you!

Javier, have you noticed what caused this issue, because I’m currently using bbPress and BuddyPress on a multi-site and the newly imported users aren’t visible in All users section, while if I try the very same csv on a plain WordPress everything is working fine.