Search Results for 'memory'

I find the normal “regenerate thumbnails” works better than “force regen” plugin.

Try upping the memory allocated to WP in your wp-config.php file which MUST be done *in addition* to the php.ini/php memory setting for hosting account.

Newsmag is a ‘bordered’ site — it uses lines to show separation of different content areas; as clearly shown in site demo. Of course, you can hide the borders if you want to. Newspaper is more ‘open’ and ‘wider.’

Speed test “zero” ? Impossible unless page didn’t load. You would likely need to optimize your site, try following my sticky post and the theme docs.

This is different theme than Newsmag — so obviously not all the same options are available. However many of the cool features from Newsmag will be in “Newspaper 5” coming “really really soon now ….” (as free upgrade, per TagDiv folk).

Just food for thought; I do NOT work here 🙂

• This reply was modified 11 years by simchris.

Thanks for the answer!!!

It was a problem with my hosting server!! They increase the memory, and now, WordPress works fine!!! :))))

Thanks!!! 🙂

Ok.
It this theme you should fix
js_composer/config/map.php on line 3533
and
wp-includes/taxonomy.php on line 3874

Just try with more then 50K records in the wp_term_taxonomy table. And you will get the same error as I had.
With memory_limit = 512M in php.ini its works. But this is not a good idea.
Definitely you need to test those two scripts with amount of data more then 100k, otherwise this isn’t a NewsMag theme this is personal Notes theme.

Log:
08-Jun-2015 20:00:39 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 72 bytes) in /var/www/site.com/www/wp-includes/taxonomy.php on line 3874
[08-Jun-2015 20:12:12 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 72 bytes) in /var/www/site.com/www/wp-content/plugins/js_composer/config/map.php on line 3533
[08-Jun-2015 20:12:15 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 32 bytes) in /var/www/site.com/www/wp-content/plugins/js_composer/config/map.php on line 3531

Have fun.

Having the same problem with js_composer.
After fresh WordPress install js_composer working just fine.
After inserting data from sql (posts) file showing blank page as site and Admin too.
When removing js_composer from plugin directory showing right Admin page again.
No other plugins installed. Debug is not showing when define(‘WP_DEBUG’, true);
Memory is 100 MB.
NewsMag is my theme.

Hello folks.

I’m also having issues with trying to save theme settings. I’m using the latest version of both WordPress and Newsmag themes. I’ve disabled all plug-ins except for Wordfence, WPBakery Visual Composer,Ultimate Addons for Visual Composer, tagDiv Visual Composer Shim and tagDiv Speed Booster.

When in the theme settings page in the admin panel, I’m able to modify most of the settings without any issue. However, when I try to click on the Block predefined style section links to modify them, the ajax spinning icon just hangs and doesn’t pop open the menu. When I pull open the dev console in Chrome, I noticed this:

Uncaught SyntaxError: Unexpected token < admin.php:1

Things that I’ve tried:

Cleared both the server cache and the browser cache.

I’ve spoken with my host, HostGator and asked them to check the admin-ajax.php and confirm that it wasn’t being blocked, which they said it wasn’t. They also stated that the maximum memory limit is already set to 256, and cannot be changed by the end-user on a shared hosting account.

Reference: http://support.hostgator.com/articles/cpanel/php-settings-that-cannot-be-changed

memory_limit = 256M (MAXIMUM)

Per Chris’s link above, I also went into the wp-config.php file and added the following line of code:

/** Increased memory allotment to prevent Ajax Errors. https://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP */
define( 'WP_MAX_MEMORY_LIMIT', '256M' );

(The official WordPress.org article Chris showed said you had to add it in prior to settings.)

Please note, this has to be put before wp-settings.php inclusion.

You can see it in-line where I included it right after the absolute path section, and before the wp-settings.php section, here:

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Increased memory allotment to prevent Ajax Errors. https://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP */
define( 'WP_MAX_MEMORY_LIMIT', '256M' );

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

Perhaps this is related, but when I’m on the front end, and try to use the left and right arrows to scroll through content in the various section blocks, the ajax loading icon just spins, and the console spits out the following error:

SyntaxError: Unexpected token < madlymanly.com/:1

Any thoughts as to what is causing the syntax error message in the console? Thank you in advance for the help!

• This reply was modified 11 years by MrChill.
• This reply was modified 11 years by MrChill.

Sorry … hit return and somehow deleted my message.

Meant to say — you can try using fewer dbase queries by having fewer blocks on homepage, try having fewer queries in sidebar, possibly not use the “suggested flyout” and also not use the megamenu. The more “go grab stuff” items you have the more it slows down dbase.

ALSO: be sure to increase your default memory with both php.ini / host panel *and* in your wp-config.php file (WP defaults to 40MB unless you actually edit your wp-config.php file to increase; it needs to be at least 64MB with 128MB recommended).

you need to Increase server memory to 64MB .. i get same problem first time install the theme.

Well, they kind of already have … on various threads.

Right now the *only* solution with Newsmag if you have this CPU spiral of doom is to use the shim plugin, and use VC as little as possible beyond the development portion of your home page. Make sure you have a lot of memory allocated to WordPress (at least 256MB from the wp-config.php file in addition to php.ini setting; you must do both!).

We started to see minor spikes once 4.4.2 came out. Prior to that zero issues. Right now we can use it, but anything later not so good. I can’t imagine if WP Bakery haven’t addressed this ins the 4.5x versions, that they still don’t “get it” and are not solving it — seems to be a “if 90% of people can use, the other 10% oh well …” which isn’t great.

Right now TagDiv is focused on (based on posts I’ve seen):
a) Newspaper 5 w/ features of Newsmag + better grid + new version of API.
b) Next Shim beta for use with Newsmag *and* Newspaper.
c) Newsmag 1.8 with bug fixes and minor updates/tweaks.
d) Dev work on possible alternative to using Visual Composer.

So — at the moment if your site dies with VC 4.42 immediately, then it’s clear you might need to go back one more iteration, and/or stick with 1.6 of Newsmag vs 1.71.

I have 2 sites still working with 1.6 and 4.42 without shim, and doing okay, but they are fairly low traffic sites. I have 3 sites on 1.71 with VC442 and the shim, and 2 of these are our larger main traffic sites which were killing MySQL in batches of every 10 minutes or so going from green to yellow to red, and back. Then CPU death.

Not sure any of that helps … not much TagDiv can do beyond the shim, and possibly providing earlier versions of VC to try for your system. Since they don’t develop VC, it’s not something they can “fix” for anybody beyond the reports they have provided to the Bakery folks as a developer/licensor in hopes of solution (and yet to see one).

Some theme devs are already leaving VC in favor of in house solutions or simpler things like Siteorigin builder (free/open source), etc. (( We’re using Page Builder by SiteOrigin with a lean WP home brew Bootstrap 3 theme for a client reporting system along with Advanced Custom Fields, and works well so far for that … )).

Anyway…. I’m sure TagDiv folk will have some reply, but likely not far different from the above rantings 🙂

Of course, it’s possible that the next version of Visual Composer will be better “optimized” …. frankly, I’m amazed they are not working with an example “DOA” server setup, reading the error logs, and trying to find what bit of code is causing the death spiral, and then FIXING it. But I’m behind on stuff for my own business, so can’t really point fingers on that 😉

1) turn off all plugins except VC
2) increase memory via the wp-config.php to 128MB or more (this is in addition to memory setting for php.ini in your hosting account – you need to do BOTH for WordPress to actually use more than 40MB)
3) be sure to turn off/clear all server caching to debug; turn off mod_pagespeed if using; if using CMS then you need to fully expire old files and refresh new ones.
4) create new page, save it; then EDIT it to add VC features.

Might help!

You solved also my other problem. During Wordfence scanning i had not enough RAM to do it. Every time before scannning i had to turn off other plugin that takes much of memory – Jetpack. Now i don’t have to do it any more, all plugins are working in same time ;]

Might be running out of memory.
Try adding line in your wp-config.php file to increase default memory to at least 96MB, and preferably 128MB.

See my sticky post on site optimization for help on how to do that. 🙂

Line 14 basically is just a line saying to “use a theme” …
define('WP_USE_THEMES', true);

Hi, sorry, yeah, somebody else thought that continuing to use VC would “demolish tagdiv theme sales and they should switch to something else” — or something like that.

Of course, VC has a nice product, but the past six months it’s become a memory hog, and as you and I have experienced some core issue just whacks certain servers (and we have dual XEON CPUs and 32GB RAM on dedicated premium box … not a VPS or something ….).

Anyway…. try the version of VC you were using previously, for editing.

Slow login can be all kinds of things … slow server, dbase overloaded, bad/rogue plugin (as I said).

You can try to increase the memory limit for php .. see my sticky topic on optimization, as I ran into this recently where I thought the server side settings were increasing memory for WP, but they were not. Basically, unless you manually increase the default memory from 40MB to 96MB or higher, WP still assumes you’re running a simple blog. So, try changing to 128MB or even 256MB if your hosting allows that.

Thanks, Chris. I’ll do that all and will report back.

a) Didn’t think of that, though theme has some light modifications.
b) We have.
c) That’s already have been done.
d) Optimizations have been done, though not all. I’ll look into that list once again. Memory limit is 256MB already – i can rise that, of course, but should I? Never received out-of-memory related errors.
e) Will do.
f) Already in use
g) Nice one, will do.
h) Response times when default themee (theme twenty fifteen) is set, are consistent 0.2+-0.05.

Thanks for feedback, and I will look into directions you gave in more detail.

Some suggestions
a) don’t use child theme, as it’s a redirect
b) ensure you have caching running on server like opcache, etc.
c) be sure to use normal WP optimizations (as per my own optimization sticky) — enough memory allocated to php, and upgrade default RAM for WP in wp-config.php -etc.
d) limit queries on post pages — meaning, avoid “most popular 7 days” kinds of things, try one query of “latest 5 stories” vs having three sidebar queries of 3 latest posts from 3 categories; try not using mega-menu to query dbase for story elements .. limit queries in footer
e) remove CSS over-rides in theme panel, move to style.css
f) consider using things like mod_pagespeed and or mod_SPDY if you serve all pages via https
g) turn off image thumbnail sizes you don’t actually use; plan layouts to limit total number of sizes for thumbs to no more than 5 or 3 if really going for speed
h) check server response time — which has nothing to do with theme and needs server to be optimized (our pages respond in 0.31 secs on avg., regardless of theme with only minor optimizations)

And of course look at some of the theme docs for suggestions from TagDiv on speed/performance.

Food for thought 🙂

• This reply was modified 11 years by simchris.

Try adding the memory line to your wp-config.php file, and bump it up to 96MB from default 40MB.

See:
https://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP

Issue is not with theme — all themes using Visual Composer as a “drag and drop page builder” are having this issue. And this only impacts some servers. We’re using NewsMag on two high traffic sites right now; one which gets a lot of traffic every day, the other gets large hits “depending on the content.”

Not sure what “SmartMag” is as this is the “NewsMag” forum, but if you read my thread then you don’t need to worry …

a) use the theme with current Visual Composer; might not impact your site/CPU depending on how your server is setup.

b) if you have a large CPU hit you will know immediately, and you can switch to using the SHIM plugin.

c) if you have a VERY high volume traffic website (e.g., millions of page views per day) you should be building a “lean framework” which doesn’t have all the pre-built options baked in, as this is not as efficient as a lean framework where you have as little as possible — e.g., TIME magazine is running on a version of twenty-fifteen theme with some custom plugins to manage editorial matters. No page builder, but lots of stuff running via cloud for fast “edge loading” via the Automattic premium platform. In that situation you would be custom building a theme to fit your needs not buying a $50 off the shelf product.

d) in our case we chose the TagDiv folk to redo our news network sites because 16 months ago when looking around they were one of the VERY few who had some clue about pagespeed optimization beyond so-called “SEO READY” … meaning, some thought given to page speed and not just “feature bloat” with some meta tags built in. We had built our own lean framework which was a pain pre-bootstrap, in 2011; went to Woo Canvas in 2012; went to TagDiv end of 2013 (has it been that long?).

But like all CMS platforms where you have a platform running on top of php, then theme(s) running on top of that, then plugins and hooks going into that, there is always a dev/test process on your end to see what works, what needs to be massaged, and what won’t work at all in your particular environment.

If you’re starting a NEW news site, I don’t think you need to worry about high traffic at this stage, as it takes awhile to build that unless you’re using bots or entirely click-bait with paid adwords per story to drive that.

————–
so, if you reads my thread you know
a) they have a fix NOW that works for those with high CPU issues
b) not all users of Visual Composer have an issue
c) the folks who make VC (not TagDiv) may optimize or fix memory issues in future version; TagDiv has NO control over that beyond working with the WP Bakery developers on the issue.
d) they may “roll their own” sideways version of a page builder which is more ‘lean’ at some point, but obviously that takes a bit of time to develop.

So, have fun and build your site 🙂

Thank You again chris s, but i tried both, increased the memory limit to 256M and deleted the visual composer folder and uploaded the fresh one, but it didn’t solve the issue.

They have been delayed by several things, those impatient amongst you might not be aware of :
a) XSS fixes for WordPress
b) API changes to YouTube
c) solutions for things like Visual Composer CPU/memory crashes

Crappy food takes no time at all; creating the perfect meal takes planning/testing and taste-testers.

I’ve been helping with ‘c’ — ‘a’ has been ongoing patches in recent weeks, ‘b’ new issue; and others not mentioned here.

This is why they didn’t make the end of April they were “hoping for.”

For those who don’t program, you should be aware this process isn’t like painting a house; it’s like painting a house where the walls keep moving, and the type of materials used for the walls may require changes to the kind of paint, halfway trough painting one wall.

Stay tuned – they will have it when they have it.

SOLUTION TO ISSUE OF WORDPRESS NOT GETTING ENOUGH MEMORY…

This assumes you have already increased the default memory allocated to php for your domain/hosting/site via normal hosting panel and/or php.ini to at least 128MB and likely 256MB ideal.

YOU SHOULD ALSO:
increase default php memory for WordPress in your wp-config.php file to 256MB. I’ve found, oddly, that for some reason, on some setups, changing the amount of memory via theme panel and php.ini does *not* actually increase amount of memory WordPress will actually use … adding the setting ALSO in config file makes difference. WordPress still thinks it will only use 40MB max by default, even if you have 256MB “allowed” on server — in our case, it doesn’t seem to SEE you CAN use up to 256MB unless you add the suggested line to your wp-config.php file.

*also note when dealing with memory settings to use “M” and not “MB” (!)

eg.

define( 'WP_MEMORY_LIMIT', '128M' );

https://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP

Last gasp … is

(assuming you tried deactivating your other plugins first; some people having issues with YOAST latest edition and conflict with Visual Composer 4.5 on some servers; issue with those plugins not theme — see the support threads on wordpress.org for yoast, for more info)

1) increase default php memory for WordPress in your wp-config.php file to 256MB. I’ve found, oddly, that for some reason, on some setups, changing the amount of memory via theme panel and php.ini does *not* actually increase amount of memory WordPress will actually use … adding the setting ALSO in config file makes difference.

https://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP

or

2) fully delete the js_composer folder, reinstall either the latest version from theme, or install version from prior theme version.