Collision between Cite and KCite

(After more thorough testing it turned out that KCite seems to have a lot of technical problem,s so I will stick with your plugin for now. However, I still think this added functionality would be a good improvement.)

Would you like to tell me about the “lot of technical problems” that kcite has? Then, I might be able to fix them. Allowing configurable shortcodes to kcite wouldn’t be a bad idea, incidentally.

Misusing this thread for a bit of advertising, my own plugin kblog-metadata has similar functionality to the cite plugin (with a widget), but also computationally interpretable metadata.

Hi,
I wrote about the technical problems I experienced with KCite in a support thread for KCite (https://www.ads-software.com/support/topic/doi-and-pubmed-does-not-work?replies=1) Please have a look at this.

It would be great if you could supply configurable shortcodes for KCite so it does not collide with Cite.

Regards
R

Hey Guys, sorry I didn’t see this thread till now.

I’m happy to change the shortcode used by Cite plugin, but only if there’s a way to do it that doesn’t mess up existing user’s implementations.

Any suggestions?

On a sidenote, if there IS a way, then perhaps it might be more logical to request Kcite to use [kcite] and Cite to use [cite] ?

Hi Maeve (and Phillip if you read this),

Firstly thanks for creating a useful plugin. I really appreciate that! (still having problems with kcite but I will write more about that in another thread – in a few days).

Perhaps a good rule would be that the plugin first launched should be allowed to keep its short code while all later plugins should have to pick something else. I think kcite was launched before cite so if this rule was to be followed it would suggest that the plugin cite should change short code.

It is unlikely that this principle will always work because there does not seem to be any monitoring of the use of short codes. The current use of short codes by plugins seems to be like the wild west.

I think it would be a good idea if both cite and kcite offered the possibility to adjust the short code. It increases the opportunities in future in case cite (or kcite) would collide with another plugin.

In this particular situation I would recommend that you add the option to the cite plugin to pick any short code. I also suggest that you set [cite] as the default short code so an update of the plugin does not cause problems for existing users.

What do you think?

Kind Regards
Ronny

Hey Ronny,

Well in theory, I think your suggestions are good.

In reality (at least for me) the challenge isn’t really WHAT would be the ideal solution, but more the HOW to implement it part, and where to find the TIME to do that. In the case of Cite, this is a few quick scripts I bunged together to solve a particular problem for a particular client. I do try to maintain and support my work, but there’s only so many hours in the day, and I prioritise my more heavily used plugins and premium plugins for obvious reasons. I will put this down on my extremely long ToDo list but honestly it’s just not a priority for me.

This plugin is up on GitHub along with my other free plugins. If you or another developer would like to do some work on this feature I would gladly accept your help! Feel free to create a pull request.

Ultimately the problem here is that the shortcodes are not name spaced. I don’t think that there is much that we can do about this. The shortcode API needs to be updated so that you could do something like “[kcite:cite]” to mean “the short code cite defined in the plugin kcite”.

It’s a fix that needs to come from WordPress rather than us I fear.