Search Results for 'nginx'

Hm. Weird. I sit corrected. I wonder if new version has some issue with Nginx …
presumably you already updated your php.ini file to increase memory, upload size and execution time from the often insufficient defaults. That was my issue with VC initially.

Probably best to roll back to prior version of VC and see if that works?

Chris. i’m running latest php version from feb. 2015 on Nginx.

/Jens

Tried

– Stop NGINX
– Delete JS Composer + Tagdiv speed booster + Theme folder
– Upload 1.7
– CHOWN
– Start NGINX

Result still blank site 🙁

Same here.

Stopped NginX
Delete Theme folder
Uploaded new version
CHOWN folder
Start Nginx

Blank

I also use Nginx, but fortunately I have not done an update theme yet. I will hold until everything is okay, but some above tips are very useful. Thanks brooooooo 😀

Yes, so you should probably go google how to manage yoru Windows Azure Cloud account — YOU are the one, bro, who mentioned that. Not sure what your azure cloud has to do with anything if that isn’t your server platform.

If running Linux – why not look at the link I provided on how to setup opcache on Ubuntu on Linux????????????????????????????????????????????????????????

AGAIN:

http://www.davidado.com/2014/09/26/how-to-set-up-nginx-with-php-5-5-and-php-fpm-on-ubuntu-14-04/

FROM THE ABOVE PAGE………..
this might not work for you, but why not try it – or contact your hosting support, or RTFM for the platform you’re using???????????????

E.g.,

# Opcache
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=6000
opcache.max_wasted_percentage=5
opcache.use_cwd=1
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.revalidate_path=0
opcache.save_comments=1
opcache.load_comments=1
opcache.fast_shutdown=1

Okay – sorry — you should wait for somebody else to help as you don’t seem to know how to google stuff for support which is entirely NOT theme related.

Apologies – I will stop trying to help you on stuff.

We use opcache/APC on our system, but I had our hosting provider set that up, so I won’t be much help on this. Ask your host company to set that up for you, or you can also do Google search for “setting up opcache on NGINX” – e.g.

http://www.davidado.com/2014/09/26/how-to-set-up-nginx-with-php-5-5-and-php-fpm-on-ubuntu-14-04/

Might be not enough memory for visual composer? Allocate 512MB for php for the domain.

You likely already did that.

Hopefully somebody else running theme on NGINX will chime in!

You will need to revisit all the optimizations done as many of the things in htaccess won’t work with NGINX as there are notable differences between Apache and NGINX setup. Similarly if running mod_pagespeed, setup has some differences.

You need to research optimizing WordPress for NGINX, on the web. Very commonly found subject. Theme itself needs nothing special for that.

Nothing to do with theme. The first byte time is managed by the server setup, connection speed, etc. How fast the server responds to a query and serves anything is entirely managed and optimized on the server side.

So, you need to consider whether you’re using Apache, Nginx, Windows, etc., and research the various ways to enhance/optimize those settings with your hosting provider or a tech consultant.

For example there are many php optimizers that can run, on server caching, faster gigabit connection to the port switch vs 100-base which is typical, etc.

@lrajabi No problem, I’m using Nginx and PHP5-FPM on my site for many years and there are no compatibility issues with newsmag theme. 😀

OK SOLVED!!!! It took me hours…. literally two days of work to narrow this down. Basically there are two database entries that could be put into the WP_OPTIONS table that specifically relate to WordPress Bakery’s Visual Composer.

In my case the two database entries specifically set parameters for the Columns and Rows of WPB’s Visual Composer. Of course components of “Pages” built on this theme use the columns from the Visual Composer.

Deleting those two entries will fix the problem.

This is likely going to be rare for most, unless you are moving directly from Newspaper and had configured some Column and Row functions in the Visual Composer.

I found this by installing a fresh copy of WordPress onto the same NGINX system and comparing the database entries in the old and new instance.

I imported the old database tables into the new one to see which one broke it. Once the options table was imported that caused the rendering issues. Going through hundreds of lines, I found the two responsible.

Easy way to find them is search for an “Option Name” with %___% wild cards in phpmyadmin. Use this specific term “wpb”.

You may get several options listed in rows in the output. The ones with Column and/or Row specifically in the Option Name should be deleted.

Actually you “can” delete all related options but keep the “wpb_js_templates” option as that is common to both a fresh install and a legacy install.

Well, now rendering is fixed for pages and columns and rows work as expected! Yay.

PS: This has nothing to do with NGINX. I confirmed the exact same issue is present on both Apache 2.4.10 with MPM-Prefork and PHP-FPM.

OK SOLVED!!!! It took me hours…. literally two days of work to narrow this down. Basically there are two database entries that could be put into the WP_OPTIONS table that specifically relate to WordPress Bakery’s Visual Composer.

In my case the two database entries specifically set parameters for the Columns and Rows of WPB’s Visual Composer. Of course components of “Pages” built on this theme use the columns from the Visual Composer.

Deleting those two entries will fix the problem.

This is likely going to be rare for most, unless you are moving directly from Newspaper and had configured some Column and Row functions in the Visual Composer.

I found this by installing a fresh copy of WordPress onto the same NGINX system and comparing the database entries in the old and new instance.

I imported the old database tables into the new one to see which one broke it. Once the options table was imported that caused the rendering issues. Going through hundreds of lines, I found the two responsible.

Easy way to find them is search for an “Option Name” with %___% wild cards in phpmyadmin. Use this specific term “wpb”.

You may get several options listed in rows in the output. The ones with Column and/or Row specifically in the Option Name should be deleted.

Actually you “can” delete all related options but keep the “wpb_js_templates” option as that is common to both a fresh install and a legacy install.

Well, now rendering is fixed for pages and columns and rows work as expected! Yay.

PS: This has nothing to do with NGINX. I confirmed the exact same issue is present on both Apache 2.4.10 with MPM-Prefork and PHP-FPM.

im running nginx and i havent problems:P . what its your problem?

We’re running Apache/CentOS; but just as an FYI, if WordPress works on your NGINX setup, the theme will work; as a theme is only a collection of style sheets that extend the built-in functions of WordPress.

Typically most developers optimize their site for NGINX using the default theme (e.g., twenty-fourteen), such as issues for Google PageSpeed; then worry about the design as secondary process once the initial WP setup is fully functional.

Hi Lucian,

Thanks for the reply. I believe it may be some sort of incompatibility with Nginx which is what my web server is running on. I may try switching to Apache to see if that fixes the problem.

Also, this appears to be an issue specific to the Visual Composer column function.

Thanks,
Lua