Upgraded concrete5 caused duplicated results of topic filter

[katzueno]

This may be related to upgrade script.

Steps to Reproduce

• Build a site with 5.7.x (5.7.5.13) with sample contents installed
• Duplicate 3 blog posts 7 times. (Total 21 pages)
• Upgrade the site to 8.0.3
• Go to blog index page and try the topic search, you get duplicated results

• Go to "A Beautiful Site Deserves a Beautiful Blog" post. Then, you see multiple "project" topics in Topics list.

*When I upgrade my company web site, "Related Posts" also gets multiple results as well.

[katzueno]

UPDATE:

If I update those existing blog and publish as a new version, these duplicated result disappears.

[s-hiroshi]

I support this issue

[aniya]

I support this issue

[aembler]

This would be best served by a community pull request.

[electroflame]

I got hit by this (thankfully on a small site!) so I definitely support this issue.

As a workaround, @katzueno's method of republishing the affected pages as new versions totally works. However, I found it to be much faster (and easier) to go to the Sitemap and edit the Attributes of each affected page. Simply toggling (deselecting and then reselecting) the page's topics (and then saving) seemed to have fixed those pages.

I can't imagine using either method on a large site, though. (I handled ~50 pages) As a short-term workaround, though, they'll work in a pinch.

[hissy]

I've found the reason of duplicated topic node

https://github.com/concrete5/concrete5/blob/a57ec9715e6cb0cabf8f625b88cdc4e6c86c1d94/concrete/src/Updater/Migrations/Migrations/Version20160725000000.php#L310

"select * from CollectionAttributeValues where akID = ?" should be "select * from CollectionAttributeValues where akID = ? group by avID"

[hissy]

This would be best served by a community pull request.

Our team (concrete5 japan) is now working on this issue, but how we can fix it? I think we can fix Version20160725000000 class, but should we add new migration class for already upgraded sites? Or, should we provide the way to fix the issue like as a package?

[aembler]

We should probably fix it both in the large migration as well as in a subsequent smaller specific migration.

…

On Fri, Jun 16, 2017 at 12:50 AM, Takuro Hishikawa ***@***.*** > wrote: This would be best served by a community pull request. Our team (concrete5 japan) is now working on this issue, but how we can fix it? I think we can fix Version20160725000000 class, but should we add new migration class for already upgraded sites? Or, should we provide the way to fix the issue like as a package? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4907 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAgNwQ3iilOLDX5xfoUXVTGtBzyGUD8Lks5sEjOogaJpZM4LW-4K> .

[joe-meyer]

I don't think we can use select * from CollectionAttributeValues where akID = ? group by avID, that doesn't seem like something mysql strict mode would like very much. SELECT DISTINCT akID, avID, atID FROM CollectionAttributeValues where akID = ? (or instead of distinct if you want to use group by that would probably work.

At any rate, does anyone have a mysql cleanup script available for this yet?

[joe-meyer]

@hissy did you guys have any luck coming up with a fix for this?

[electroflame]

Any updates on this issue (or any of the potential fixes)? It's a pretty major problem when upgrading semi-large to large sites, as all the pages have to be updated by hand.

It's currently preventing a couple of my sites from being upgraded to any current 8.x version, as it's easily a few hours of work to manually update the pages.