0.5.3 bug: page-titles and pages output still swapped!

i gave it another try to upgrade from 0.4.3! this time to still hot 0.5.3!!

in “page-titles” i still see the “pages” and vice versa. its still mixed up! at least here on our testsystem with fresh db-dump and code-checkout from the status of production (>400 piwik sites/customers…) .

maybe someone can confirm or double check it?

The double down arrows on the menu means there’s a problem in your system.

Try clearing the tmp folder.

yes i do really have a problem: pages and page-titles are swapped! (like in 0.5, 0.5.1! i did not try 0.5.2. but now its broken in 0.5.3 anyway…)

the other minor problem with the two arrows was just a problem of my changed template loading a specific js twice. i managed to fix that…

but, pages and page-titles swapping is still there! has anyone the same effect?

Your image shows only that you have URLs for the page titles. Not that you have page titles in the URLs column. Do you really have them swapped? Or do you simply have URLs in the page titles? If the latter is the case switch the range to “day”.

this is a report on data that was acquired on productive system: here a day view which is swapped. in pages it does not have any data, as there were no page-titles processed at this time (running 0.4.3).

on productive system everything works as it should. one sees exactly the same output but under pages!

That “+ online-schalter” somehow looks like a title, but I assume it’s a query-string?

Anyway, there is nothing “swapped” (*). You just don’t have any page title data for that day. The page title table is populated with the URL if there is no page title saved. Thus you get the exact same data for both tables on that day.

If you had checked today on a 0.5.3 production system you had noticed that.
See, you cannot test everything by just copying the db :wink:

(*) “swap” means that A displays B and B displays A, thus each displaying the wrong data. You had better used “duplicate” and it would have been clear from the beginning that you got confused because you had never seen this function in production.

its urls, action_name, aka pages, that we set by our application. under 0.4.3 it works like a charm!

piwik_action_name = ‘online-schalter/formfoo/actionbar’;
piwik_log(piwik_action_name, piwik_idsite, piwik_url, piwik_vars);

it is swapped!

on 0.4.3 there are no page-titles registered (as this feature was not there). so after upgrade to 0.5.3 there should be also no data! but there is. and its exactly the data i see on 0.4.3 under pages!

but on 0.4.3 there were pages registered. but after upgrade to 0.5.3 i see none!

and of course am i able to dump the db and install that dump on test system and using the same code. i did then upgrade the testsystem to 0.5.3 via updater that also changes the db. thats completely the same way as if i would upgrade production system. but without messing up everything for all our customers! which would have been happened!

so if i get you right you do not see the same effect on your old data when upgrading from 0.4.3?

Not correct. I explained why that is so. “The page title table is populated with the URL if there is no page title saved. Thus you get the exact same data for both tables on that day.”

Bolero, can you post a screenshot of both reports?

So you are not seeing the same reports as on : http://piwik.org/demo/index.php?module=Cor…;date=yesterday correct?

Which version of the Javascript code are you using? Please try updating to the latest which might help.

in 0.4.3 or 0.5.3?
i’m talking about how data looks that was collected on 0.4.3 after the upgrade to 0.5.3 !

[quote=matthieu @ Dec 17 2009, 02:51 PM]Bolero, can you post a screenshot of both reports?

So you are not seeing the same reports as on : piwik.org/demo/index.php?module=Cor…;date=yesterday correct?

Which version of the Javascript code are you using? Please try updating to the latest which might help.[/quote]

full ack. i see the same as demo on our test:

please check out your own demo. example on 2009-12-02 :

you see the wrong data and the effect that i describe here as well:
earlier versions collected pages not page-titles! so this output is imho wrong!


and you see the mix of pages and page-titles in the week from 7-13 december (you updated demo on 7. so on 8. it began to mix up pages and page-titles):


but glad seeing it broken also in demo! so its not a problem at my site…and glad i did not upgrade on production yet.

unfortunately this won’t be fixed as it is the expected behavior. I can understand that it appears mixed, but it was decided that the pages URLs report should not contain the old data, as the old data might not be URLs (if the user overwrote the names using the Javascript api). This is a won’t fix.

I do. But this is not what toastbrot claims. He claims the tables are swapped. I cannot see any swapping for these tables on the link you posted, can you?

Exactly. Again: “The page title table is populated with the URL if there is no page title saved.” Read: for old data you will get a “mix of pages and page-titles”, of course!
There is one thing I didn’t notice and that Matthieu mentioned in his last post: for ranges that contain only old data the page-URL table will show no data. If the range includes old and new data you get the page URLs (new data) in the page-URL table and a mix of URLs (old data) and titles (new data) in the page-title table.

hm. i see. we exactly overwrote those urls by api with some logical information that is not an url. and we can not change that behavior on all our customers in all pages! (i talk about 500 customers with each around 100 pages. we could trigger a full-generation of all those pages, but thats nearly impossible to get done in even some days with full computable power…) and we still have then the data-mix in backend.

in our case its a complex webapp, where nor url nor the page-title does tell the customers anything they want to know about the process (sometimes its even the same step/info but completely different urls, ssl, …). so we’re not able to use it like this. i have to think what might be a solution to get around that data mixture…

do you know any?
maybe: disable page-titles module and have all old pages-data under pages visible. possible?

So the current behavior should work fine for you? If you overwrite page names with custom names, the old data would appear in Page Titles report. The new data (the overwritten names) would also appear in Page Titles. Is there an issue?

no upgrading behavior is wrong!

old pages-data is based on urls (in my case something different, but does not matter) that is now presented as page-titles. and new urls are presented stilla as pages. that can not work for anyone! because you loose old data in that category and its suddenly in a new, where from the time of upgrade different type of data is collected. thats simply wrong!

you can not make page-titles out of collected urls and mix them together. thats not right! its not the same!

i really do not see the point why you “convert” pages to page-titles! why not keep them as pages? (for some people it would be useful to have them also as page-titles additionaly if the did not use them as urls. but im shure 99% of the users did use them as urls. so for all them its broken.)


check your demo. how should one make a monthview over urls. when in between the old data has gone because of upgrade!
example december:
urls 1.-7. are now in page-titles
urls 8.-… are now in pages
so one looses old data because its suddenly somewhere else! and in page-titles its suddenly a mix of new page titles AND old urls! those are different data one can not compare.

another example in page-titles in monthview you see in demo “/index 12976” and "Piwik - Web analytics - Open s… 21905 " which is actually the same page, but just makes a mess!

sorry, but i really dont get the point why you did this!

the only correct solution i know is:

  • upgrade does not change anything on old pages. just keep them there where they are under pages!
  • upgrade does ask if pages should also be visible under page-titles. (but default is no)