Name conflict with other shortcodes

[No3x]

The current shortcodes are in name conflict with shortcodes used by other plugins or themes. E.g. the tooltip shortcode in themes from"elegant themes". We could avoid conflicts by prefixes or overwrite existing shortcodes.

[Sinetheta]

Ouch, that would be a pretty breaking change. What's the standard here? Evidently "elegant themes" didn't feel the need to namespace theirs.

Maybe have it as an option to namespace them or not?

Currently the options to "disable" shortcodes are just cosmetic, it removes the button from the WYSIWYG but they still parse on the front-end. Maybe turn them into a true disable, so people can avoid conflicts by just turning some of them off as well.

[No3x]

Unfortunately there is no standard for shortcode naming. There is also no namespace support or something similar. The Codex says

"add_shortcode: There can only be one hook for each shortcode. Which means that if another plugin has a similar shortcode, it will override yours or yours will override theirs depending on which order the plugins are included and/or ran."

(So I was wrong: you can't even do a specific overwrite) The disable "feature" would only be a workaround since you can't control which shortcode should be used (in case another plugin hooks your shortcode afterwards). In my opinion each plugin should prefix his own shortcodes as convention. This wouldn't affect the user as much since each shortcode uses a "wizard" for setting up. They shouldn't be too hard to implement.

[Sinetheta]

I meant that "disable" would stop the shortcode from even being registered instead of blindly activating them all before init.

I'm open to a major version rollover though if you think namespacing the the shortcodes is the right call here. I would be otherwise worried about cluttering up content, but BS: isn't a very obtrusive addition.

[No3x]

@Sinetheta: I'm not sure how to implement the prefixes because it's a architectural issue. The shortcode-name is also used in the JS - this would need a JS controller where the plugins could ask for their prefix. 1) We could use just a convention that each shortcode must start with bs_ 2) We could use a wrapper for add_shortcode( $tag, func ) like bs_add_shortcode and prefix the $tag in there. 2.1) We could make static functions therefore which would mean in the plugins BootstrapShortcodes::bs_add_shortcode('tag', 'func'); 2.2) We could make global functions which would make the call easier bs_add_shortcode('tag', 'func'); But we could not use the class variable $shortcodes to do further checks since they are not static. (atm)

I'm not sure about the concept. May you could give me your view about this and we could discuss it.

[Sinetheta]

I don't mind wholesale changes. You're right that the way filenames are currently tied to particular function names is lamesausce. It was mostly me trying to trim down the codebase a bit. Although most of the plugin has been rewritten at this point, it was a ball of yarn I inheritted it (forked from Bootstrap 2).

What really needs to happen is for a subclass to be created, of which each individual shortcode is a member. Then each one can have whatever info it needs, they can each be instantiated separately. Unfortunately I just haven't had time for a major rewrite this week (changing jobs).

I'll happy to accept any non-breaking pull request, but let's make sure that we only change the syntax once for the users, so that all of the shortcodes change together, and everything else is a behind-the-scenes minor version increment.

[No3x]

I've created a plugin super class and created a subclass for each plugin in the inc folder. In the bootstrap-shortcodes.php I include each file of the inc folder dynamically and make instances of the classes/plugins. Do you think that's the right way?

[Sinetheta]

I think maybe one "type" of subclass would do, each shortcode being a particular instance of that subclass, with it's properties changing (eg: name, shortcode, includes). But whatever gets the job done for you. It's not a big enough project to care about organization too much, the sooner we can get these things namespaced the better, so that there aren't compatibility problems in the future.

[Sinetheta]

Nice one @No3x, 2.0 is up on the plugin repository, I added you as a contributor :metal: