Search Results for 'install'

Theme cannot break image location or remove items from your media lists/folder.

You should regenerate thumbnails to fit news sizes used in theme.

If you check your media/uploads folder via FTP, you might be able to check on the permissions for that folder. If you accidentally deleted that, it would not be recoverable; hopefully you backed up your site prior to making major changes.

An example image link, like so – does appear missing:
http://dance.land/wp-content/uploads/2014/12/nathan-barnatts-curious-dances.jpg

However installing the theme does not delete your /uploads/ folder unless you did that manually. If you deleted the /uploads/ folder, or the /wp-content/ folder for some reason, then that would have deleted the images folder.

Ideally you should double check with your hosting provider in case they have some bizarre setting which impacts that folder in some way.

• This reply was modified 11 years by simchris.

Visual Composer was updated with theme 1.31 the other day; it updated the version of Visual Composer which broke due to WordPress 4.1 update.

The plugin is updated separate from the theme, as it’s a plugin. So you have to delete old plugin, and install the newer version.

Newsmag 1.31 just updates the plugin, which can be installed alone if you already have Newsmag 1.3.

The updated version of Visual Composer (changelog):
19.12.2014 - ver 4.3.5
- Compatibility with WP 4.1

For images, make sure you have regenerated thumbnails for the theme sizes.

You dont need to activate license. See the theme docs … Link right side of this page for more info.

To activate the plugin, you furst install it, then activate from the plugins page.

Ok, so maybe it’s just that the demo posts don’t work well with being edited? Because I created a brand new post and decided to use that same 1024×576 image, inserted it the same way and set it to be tagdiv fullwidth and in modal and it works! http://afro.freshmedleydesigns.com/?p=155

I’ll continue to do more test posts and see what happens. But I’m wondering, if on my live site, for posts I already wrote way prior to installing the theme, would that weird issue occur if I go edit old posts and want to set images to fullwidth? (I’ll test some as well and see and let you all know).

Switch to default wordpress theme
Turn off all plugins
Delete old vc plugin completely
Install new plugin
Turn on vc plugin
Rest theme
Test, then turn on other plugins.

You should turn off all caching before doing any updates.

Hope that helped.

SOLVED / SOLUTION
I figured it out,

1- redownload the theme from your themeforest account first and unzip the folder on your desktop.
2- Then login to wordpress and deactivate then delete the plugin Visual Composer.
3- Now in wordpress click on install plugin, brows to the theme folder on your desktop and look in the plugins folder for the the Visual Composer zip and select it.
4- Once uploaded and installed, activate and thats it!

@sgoadmin
Not right now … trying to migrate an old ecommerce system from old platform (cubecart) to new platform (woocommerce) so we can switch mod_SPDY back on for the server, trying to install custom local copy of “piwik” on subdomain with wildcard SSL, and generally overloaded at the moment …. 🙂

• This reply was modified 11 years by simchris.

I have not yet tested/debugged this personally as waiting for the dot revision to theme to coincide with WordPress 4.1 update, and VC update. Once all that in sync, hopefully for Saturday, I’ll take a stab at debugging my own install by starting with only VC and theme running and all other shenanigans turned off, then go from there.

In case anybody following this somewhat important topic for those of us doing reviews 🙂

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.

i have a windows azure and i create the WIndows server 2012 Vm and install xampp 🙂 so this is the server issue or my xampp configuration are incorrect?

Hi Lucien,

Could I made one suggestion?

I have implemented bbPress and it works fantastic now that I have all the settings figured out. I’ve also installed the “bbPress Topics for Posts” plugin, essentially replacing the WordPress commenting system with bbPress.

While the forum on its own looks great, the comments aren’t so pretty. Could tagDiv also look into this plugin and theming the comment area so it is a bit nicer looking? I know I am in the vast minority for this need, but it would be a nice touch.

Cheers,
Mark