Hello! I found the upgrade process does not work as easy as 1-click. It simply has errors here or there. Therefore, I would do a clean install. I need some advice on the steps because I do not know why the settings are missing after I restore the database every time. Thank you!
Here’s what I did:
- Backup database
- Backup modified files like config.local.php, stylesheet, meta, etc …
- Upgrade using upgrade center
- Backup upgraded database
- Rename the public_html to public_html_old
- Do clean install
- Install/uninstall/disable Add-On that matches previous settings
- Restore upgrade database
- Copy modified files (compare and make adjustment if necessary)
- Clean up files in var/compiled and open store
What else am I missing? Why do I need to define logos and goes into save various settings again? I thought these settings are stored in database:confused:
Anyone’s help would be greatly appreciated! Thank you!
Upgrading from 2.0.11 to 2.0.12?
Did you copy /images from your old installation to your new installation?
Bob
Yes, I did. I am only stuck on the losing existing settings … Thanks!
The logos are stored in /YOURSKIN/basic/customer/images. You probably need to copy those from your old install to your new install.
I’m not sure what is happening with your settings. It sounds like your did everything properly. The only thing I can suggest is comparing the cscart_settings table from the old and new database. If they are the same, then your setting should be the same. Is it all the settings which are not carried over or only some?
Bob
hello, Joe. I am not sure what happen either. Actually, the setting are there! However, I would need to go to each page and hit [save] again after database restore.
Regarding the logo problem, I used a different name like websitename_logo.png, it should link up correctly. However, it is still pulling the one from the original template.
I need to setup to link to the correct file again! 
The filenames for the logos are stored in /skins/YOURSKIN/manifest.ini. The manifest.ini file in a clean install will have the original template filenames. When you update your logos in Design->Logos, the new filenames are written to manifest.ini.
Bob
[quote name=‘jobosales’]The filenames for the logos are stored in /skins/YOURSKIN/manifest.ini. The manifest.ini file in a clean install will have the original template filenames. When you update your logos in Design->Logos, the new filenames are written to manifest.ini.
Bob[/QUOTE]
So, I should backup this file too before I upgrade?! Thanks!
[quote name=‘grabbags’]So, I should backup this file too before I upgrade?! Thanks![/QUOTE]
Yes. Otherwise you will need to reset your logos.
Bob
Thanks! I will give it a try very soon.
It is because I noticed the upgrade features leave out many features during the upgrade.
For example, 2.0.12 supposes to have the ability to define the rights for ‘promotion’ under catalog management. however, the upgraded version from 2.0.11 doesn’t have it …
A lot of times, I found clean install solves most problems …
[quote name=‘grabbags’]It is because I noticed the upgrade features leave out many features during the upgrade.
For example, 2.0.12 supposes to have the ability to define the rights for ‘promotion’ under catalog management. however, the upgraded version from 2.0.11 doesn’t have it …
[/QUOTE]
Do you have a list of the settings missing on an upgraded installation? These need to be reported to the developers so that the developers can address this in a future upgrade package.
I just checked in an upgraded install and the ‘Manage promotion system’ is in the Add-ons section instead of the ‘Catalog’ section - it looks like the upgrade script missed the change in section. For anyone who wants to address this, you can run the following query:
UPDATE cscart_privilege_descriptions SET section = 'Catalog' WHERE privilege = 'manage_promotions' AND lang_code = 'EN' LIMIT 1;
Bob
hello, bob. thanks for the information. no. i do not have the ‘list’. I only submit to bug tracker once a while. sometimes, they just don’t find the problem … and i don’t have time to setup the environment for them to check.
however, here’s another one I noticed the upgrade from 2.011. for example, catalog management is enable for a group. however, it keeps saying access deny if admin from that group login.
Thanks!
[quote name=‘grabbags’]however, here’s another one I noticed the upgrade from 2.011. for example, catalog management is enable for a group. however, it keeps saying access deny if admin from that group login.[/QUOTE]
I just tried this on an upgraded site and I do not get this message. I have a “Product administrator” usergroup which has only “Manage catalog” and “View catalog” permissions. When I log in as a product administrator, I can make changes to both categories and products. A few extra tabs appear which should not and this has been reported:[url]http://forum.cs-cart.com/vbugs.php?do=view&vbug_id=1671[/url]
Was your catalog management usergroup created when usergroups were called memberships?
I also reported the inconsistency for the “Manage promotion system” privilege:
[url]http://forum.cs-cart.com/vbugs.php?do=view&vbug_id=1720[/url]
I really dislike any DB structure inconsistencies between upgraded and new installs so I reviewed the cscart_settings table from a fresh 2.0.12 install and a site that started life as 1.3.4-something. I found no issues - both schemas contained all the same settings. I do know that the developers have missed some things in the SQL upgrades in the past so I usually compare the upgrade DB to a new DB.
I encourage everyone to report their problems in the Bug Tracker. You are correct that they sometimes fail to duplicate the problem but they will not even be looking for an unreported bug. Two things that improve your chance of getting problems fixed are:
[QUOTE]1) Duplicate the problem in the demo store whenever possible, then inform them of the steps to take to duplicate the problem. A problem that can be duplicated in the demo store cannot be shrugged off as a unique server or setup issue;
2) Search the Bug Tracker to see if the problem has already been reported then add your comments. This, too, informs the developers that they are not dealing with a unique problem.[/QUOTE]
Bob
[quote name=‘jobosales’]
I encourage everyone to report their problems in the Bug Tracker. You are correct that they sometimes fail to duplicate the problem but they will not even be looking for an unreported bug. Two things that improve your chance of getting problems fixed are:
Bob[/QUOTE]
Please understand there are a lot to report and I do not work full time for it. It is taking too much time to report all the single details.
For example, I have previously assigned features to a product. When I try to bulk update the features, It did not delete the old value or apply the new assigned value. It is still pulling the old value. I can only disable it from appearing. Once I enable that feature again, it keeps using the old value.
It is their jobs to find out … I can only provide the hints. I cannot setup an environment for them to test on each bug found. Thanks!
grabbags-
The only “hints” we provide to the developers are what we post to the Bug Tracker or Helpdesk. It is well-known (an you have been here for quite some time) that the developers really do not check out the forums. Yes, it is “their jobs to find out,” but they are not telepathic.
Additionally, the developers will only ask for access to your installation if they are unable to duplicate the problem on their systems. This is why it is always good to check if the problem can be duplicated on the demo site and report if it is reproducible.
I tried to reproduce your problem in the demo store. I ran into a problem but it seems different(and contrary) to the problem you mentioned. I have reported the problem here:
[url]http://forum.cs-cart.com/vbugs.php?do=view&vbug_id=1727[/url]
You might want to add your comments to the Bug Tracker post if your problems are similar to what I have added.
Bob
hello bob,
that’s good that you’re very patience to provide the steps by steps. In fact, I did report it before, however, they are not able to duplicate the problems. I am too busy to provide a duplicate of my store so that that they see what I see. All I know it screws up my existing features. To ensure eachi product is correct is to manually assign feature on each one. Mass applies sound good, but no perfect.
Hello Bob,
I add comments to your post. BTW, just wonder which file backup for blocks record? The clean install seems to lost the block settings. Thanks in advance.
[quote name=‘jobosales’]grabbags-
I tried to reproduce your problem in the demo store. I ran into a problem but it seems different(and contrary) to the problem you mentioned. I have reported the problem here:
[url]http://forum.cs-cart.com/vbugs.php?do=view&vbug_id=1727[/url]
You might want to add your comments to the Bug Tracker post if your problems are similar to what I have added.
Bob[/QUOTE]
The block layouts are stored in /skins/basic/customer/blocks.
Thanks for adding your Bug Tracker reports.
Bob
Thank you, Bob for the information. However, those are only the templates.
It doesn’t store the settings. For example, I setup a banner block at the bottom of the page. Once I restored the database, it disappeared. I need to set it up again. Weird.
Thanks anyway.
[quote name=‘jobosales’]The block layouts are stored in /skins/basic/customer/blocks.
Thanks for adding your Bug Tracker reports.
Bob[/QUOTE]
The settings are stored in the database in the cscart_blocks and cscart_block_* tables. The TPLs determine the position within the page area.
As best I can tell, here is how they work.
If your block appears in the central area of the Home page, find and open /skins/YOURSKIN/customer/blocks/locations/index/central.tpl. Inside that file, you will see something like this:
{block content=true wrapper="blocks/wrappers/mainbox_general.tpl"}
{[B][COLOR="Red"]block id=11[/COLOR][/B] template="blocks/products_multicolumns.tpl" wrapper="blocks/wrappers/mainbox_simple.tpl"}
{block id=40 template="blocks/products_multicolumns_small.tpl" wrapper="blocks/wrappers/mainbox_simple.tpl"}
{block id=9 template="addons/tags/blocks/tag_cloud.tpl" wrapper="blocks/wrappers/sidebox_general.tpl"}
The blocks will be displayed in the same order they appear in the TPL so, for instance, if I swap the second and third line, the blocks in the storefront will also change positions.
As to how these lines relate to the DB, looking at the second line, the block_id is 11. The block_id is used to link the the specific block to its settings. If you search the cscart_blocks table for block_id 11, you will see whether a block is active/disabled and what locations it appears in.
If you search the cscart_block_descriptions table for block_id 11, you will find the block name (e.g., Featured products). The cscart_block_links table associates items (e.g., manually assigned products or pages) with a block. From what I can tell, the cscart_block_positions table stores the tab order for the product pages.
Most of the settings are stored in the cscart_block_properties. These are the settings you see in the Design->Blocks.
When a block is created/saved, the various DB tables are updated and the appropriate TPL in /skins/YOURSKIN/customer/blocks/locations has a line inserted to point to theblock information in the DB.
Check your TPL file to see if it contains a line(s) with the block_id information, as above. If not try copying these files from your old installation (note that if you have created new blocks, you will need to merge these in the TPLs).
Bob
Thank you, Bob. I will look into it next time I do upgrade again. I have already did all the blocks again! 