sorry once more,
I´m not familar with php and/or sql at all and so the instruction from CaptRob didn´t also help me to solve this problem.
Will there be an upgrade for this issue in the near future?
@remmelzwaal
Thank you.
I ended up upgrading/installing to the current beta release (with a new config file - did override the existing database tables) and doing after that a file compare of the local full package and the online content.
Then I did update the online content (deleted all old files/folders of past versions) and:
voilà!
That did it and everything is working again.
Regards,
Barcelo
@barcelo I have installed the Piwik beta 2.14.1-b1 https://builds.piwik.org/ In this beta the web-cron bug is fixed (301 Moved Permanently). Now everything works fine.
After I have had the same errors and the workarround was not working I have installed the Piwik beta 2.14.1-b1 an I get the same error again.
SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘log_visit.config_os’ in ‘field list’
I did the workarround again
ALTER TABLE piwik_log_visit ADD COLUMN location_browser_lang VARCHAR(20) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_os char(3) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_browser_name varchar(10) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_browser_version varchar(20) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_resolution varchar(9) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_pdf tinyint(1) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_flash tinyint(1) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_director tinyint(1) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_quicktime tinyint(1) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_realplayer tinyint(1) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_windowsmedia tinyint(1) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_gears tinyint(1) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_silverlight tinyint(1) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_java tinyint(1) NOT NULL;
ALTER TABLE piwik_log_visit ADD COLUMN config_cookie tinyint(1) NOT NULL;
And I get the same second error again
Fehler
SQL-Befehl:
ALTER TABLE piwik_log_visit ADD COLUMN location_browser_lang VARCHAR(20) NOT NULL;
MySQL meldet: Dokumentation
#1060 - Duplicate column name ‘location_browser_lang’
Any idea?
The answer is right in front of you:
#1060 - Duplicate column name ‘location_browser_lang’
Means, that the column “location_browser_lang” in the table “piwik_log_visit” already exists.
So, do the rows once at at time instead of altering the whole block (that you posted).:)-D
Cheers, Barcelo
Ok, I finally found out, how to use phpmyadmin.
I copied the piwik-beta to my analytics-directory and after that i did the workaround.
Now piwik works correctly again.
Thanks to all instructors
Thanks a lot for your help
Now it´s working fine again!
I am lucky (
Every time we try to upgrade Piwik we seem to hit a problem.
I eventually managed to complete the upgrade from 2.13.1 using the workaround above - However, our database tables seem to be named slighlty differently to yours. I had to modify the table name from stat_log_visit to log_visit.
Equally, in this thread 301 Moved Permanently the workaround assumes the table name is piwik_log_visit, which I changed to log_visit.
What’s going on here - Why the different table names?
Has some previous upgrade that renamed tables failed (or similar)…
Any help welcome - We could really do without having to try and manually perform each database upgrade.
@adamradford
Have you ever heard about “table prefix”?
Search the web and you will see the light ::o
piwik_log_visit or stat_log_visit or log_visit is NOT a problem of piwik (the bold letters are a table prefix).
This depends on how YOU installed Piwik to your database. So check your Piwik database tables if they have a prefix or not
And if they have a prefix, you have to change the ALTER commands to your special needs.
So, please don’t blame someone at Piwik :)-D
So as a follow up question then, is “not” having a table prefix the reason why the automatic database upgrades fail? Or is that a separate issue?
Then in your case (without table prefix’s) it’s:
ALTER TABLE log_visit ADD COLUMN location_browser_lang VARCHAR(20) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_os char(3) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_browser_name varchar(10) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_browser_version varchar(20) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_resolution varchar(9) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_pdf tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_flash tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_director tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_quicktime tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_realplayer tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_windowsmedia tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_gears tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_silverlight tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_java tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_cookie tinyint(1) NOT NULL;
EDIT:
you renamed your table -> that was wrong!
-> rename it back to “stat_log_visit” (as it used to be)
Then do the following:
ALTER TABLE stat_log_visit ADD COLUMN location_browser_lang VARCHAR(20) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_os char(3) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_browser_name varchar(10) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_browser_version varchar(20) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_resolution varchar(9) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_pdf tinyint(1) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_flash tinyint(1) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_director tinyint(1) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_quicktime tinyint(1) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_realplayer tinyint(1) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_windowsmedia tinyint(1) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_gears tinyint(1) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_silverlight tinyint(1) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_java tinyint(1) NOT NULL;
ALTER TABLE stat_log_visit ADD COLUMN config_cookie tinyint(1) NOT NULL;
Apologies for the confusion, I didn’t rename the table - I meant to say that I renamed the table name in the scripts. My table is called log_visit.
in this case as mentioned first:
ALTER TABLE log_visit ADD COLUMN location_browser_lang VARCHAR(20) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_os char(3) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_browser_name varchar(10) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_browser_version varchar(20) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_resolution varchar(9) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_pdf tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_flash tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_director tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_quicktime tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_realplayer tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_windowsmedia tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_gears tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_silverlight tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_java tinyint(1) NOT NULL;
ALTER TABLE log_visit ADD COLUMN config_cookie tinyint(1) NOT NULL;
Has anybody written a data restoration script yet?
I have to add to this discussion as it might help others that have this problem. After hunting for days I saw it suggested on some thread or another to check the Administration > System Check which I did. It came up with one error and that was a missing file. Namely .phpstorm.meta.php which as you can see is a hidden file. I went back to my ftp program and viewed hidden files and this showed up. I moved it to the server and bingo! The whole thing works with no errors.
I hope others find this helpful.
In this thread there seem to be two types of problems, sometimes mixed together.
One of them is the non-existence of certain columns in table log_visit.
The other are non-existent indexes in objects derived from the class Visitor through extended classes.
My problem is the second one as I seem to have all the necessary columns in log_visit.
I noticed the problem after an upgrade from piwik 1.x to 2.15.0.
I used the one-click update.
After the update I noticed that the plugin UserSettings was still there but deactivated.
Piwik suggested to uninstall it, so I did.
To get the Browser identification I need to turn on the plugin DevicesDetection.
It apparently replaces the old UserSettings plugin.
This produces warnings regarding undefined indexes for what seem to be extended objects of the Visitor class.
It also is noticable through the missing browser icons and in the visitor log and browser detection just does not work.
The warnings concern the class file Visitor.php.
They all are in this format and only differ on the missing index of the extended Visitor object:
WARNING: <path_to_piwik>/piwik/plugins/DevicesDetection/Visitor.php(34): Notice - Undefined index: config_device_brand - Piwik 2.15.0 - Please report this message in the Piwik forums: http://forum.piwik.org (please do a search first as it might have been reported already)
Which tables house the columns for the extended Visitor details?
Is there a way for me to check which arguments are used exactly to build the extended Visitor object?
Is it possible that extended indexes of Visitor objects are read before they had the chance to be written or extended?
I hope that someone is able to give me a hint in which direction to look for a solution.
Was anyone able to solve this problem by now?