I've spotted an issue with the tags merging feature I think. On a client site, they've merged several tags into a new one, and in the back office they show up under the correct tag, but on the front end they are listed under the old tag.
It doesn't look like the source code is publicly available, but I've decompiled it using Reflector, and it looks like your package updates the tags using SQL, but it doesn't actually update the published documents, so the front end won't reflect your changes until the tagged content is re-published.
Right clicking on the content node and doing a re-publish won't work, as it just rebuilds the umbraco.config file from the cmsContentXml table, which only gets repopulated when you physically re-publish the page.
You need to update the move/rename/delete code to republish all of the tagged documents so that the front end reflects the changes you've made in the tags manager. If you're happy to share the source, I'm more than happy to make the changes, as I have a client that needs it fixing.
Below is a link to a complet zip file of an umbraco site, a database backup and also the project code. Sorry it's a "dump" but at the moment I haven't the time to split it all out and provide it in a nicer way.
I'd definitely like to know the code changes you make so I can incorporate into the package.
One thought re the merged tags, and it is a small risk, but if you iterate through the nodes and republish, you might be publishing changes to content that aren't meant to be published, ie work in progress by content editors. Not sure if the API provides a way of checking if the node has got unpublished changes.
Anyway, I look forward to hearing back from you - feel free to drop me a note directly - [email protected]
For the republishing, I believe there is a way to check if content is already published, so that we can get it to only publish things that should be published. I'll have a look at this next week after the bank holiday weekend :)
I'll be sure to send you back any changes that I make!
I've hacked together a quick and dirty version to fix my immediate problem site, but now that I've looked into this a bit further, the nasty part of making this totally re-usable is finding all of the properties that are tags based. Checking on every document is pretty slow, especially for sites with a LOT of tagged content.
I guess the two options would be to allow the users to specify field aliases to look for in a config file (nice and fast, as no DB lookups involved), or maybe build up a list of DocTypes and associated tags properties the first time the tags manager runs and then cache it for a while to minimise database hits. Do you have any preferences?
Let me know, and I'll write something more robust that can be merged back into the plugin code!
As per your last post, yes, you are right, knowing which property on the document is a tag type. If it is the original type then they may have the same guid in the database which may provide a hook to work from ? Just thinking off the top of my head (which sometimes works, sometimes not!).
Here is the original version - it is a zip from the start of the year, but there've been no changes.
Merging/Renaming/Deleting Tags not reflected in the front end
Hiya,
I've spotted an issue with the tags merging feature I think. On a client site, they've merged several tags into a new one, and in the back office they show up under the correct tag, but on the front end they are listed under the old tag.
It doesn't look like the source code is publicly available, but I've decompiled it using Reflector, and it looks like your package updates the tags using SQL, but it doesn't actually update the published documents, so the front end won't reflect your changes until the tagged content is re-published.
Right clicking on the content node and doing a re-publish won't work, as it just rebuilds the umbraco.config file from the cmsContentXml table, which only gets repopulated when you physically re-publish the page.
You need to update the move/rename/delete code to republish all of the tagged documents so that the front end reflects the changes you've made in the tags manager. If you're happy to share the source, I'm more than happy to make the changes, as I have a client that needs it fixing.
Hi Tim
Below is a link to a complet zip file of an umbraco site, a database backup and also the project code. Sorry it's a "dump" but at the moment I haven't the time to split it all out and provide it in a nicer way.
I'd definitely like to know the code changes you make so I can incorporate into the package.
One thought re the merged tags, and it is a small risk, but if you iterate through the nodes and republish, you might be publishing changes to content that aren't meant to be published, ie work in progress by content editors. Not sure if the API provides a way of checking if the node has got unpublished changes.
Anyway, I look forward to hearing back from you - feel free to drop me a note directly - [email protected]
Cheers, Nigel
Hi Nigel,
Thanks! You've not put the link in though :)
For the republishing, I believe there is a way to check if content is already published, so that we can get it to only publish things that should be published. I'll have a look at this next week after the bank holiday weekend :)
I'll be sure to send you back any changes that I make!
Hi Tim
Here's the link now - sorry I omitted last night...
http://www.yoyocms.co.nz/images/Yoyocms.Umbraco7.TagManager.zip
Happy coding - I will be away until 30 August on holiday so if you've any queries, etc I won't be able to respond until then.
Cheers
Nigel
Hi Nigel,
I don't suppose you have the source for the v6 version of the plugin as well do you?
Hey Tim
I have the source for my original package - not sure what versions it is compatible with.
More than happy to sharte this too - will post a link in the coming days for ya.
Cheers
Nigel
Hiya,
I've hacked together a quick and dirty version to fix my immediate problem site, but now that I've looked into this a bit further, the nasty part of making this totally re-usable is finding all of the properties that are tags based. Checking on every document is pretty slow, especially for sites with a LOT of tagged content.
I guess the two options would be to allow the users to specify field aliases to look for in a config file (nice and fast, as no DB lookups involved), or maybe build up a list of DocTypes and associated tags properties the first time the tags manager runs and then cache it for a while to minimise database hits. Do you have any preferences?
Let me know, and I'll write something more robust that can be merged back into the plugin code!
Cheers,
Tim.
Hi Tim
As per your last post, yes, you are right, knowing which property on the document is a tag type. If it is the original type then they may have the same guid in the database which may provide a hook to work from ? Just thinking off the top of my head (which sometimes works, sometimes not!).
Here is the original version - it is a zip from the start of the year, but there've been no changes.
It was built against v6.07 so all good there.
Keep me posted.
Cheers
Nigel
is working on a reply...