If you like to let the user be chosen by his username, I would recommend that you look at the plugin AuthorSelector. You need to include the js file jquery.tokeninput.js and a custom snippet of js. You can use authorselect.js if you give your input box the class "MultiComplete".
I couldn't get jquery.tokeninput.js to work, sadly. I still don't understand why
But at least it enabled me to write this snippet.
Now you can start typing an username and a dropdown box gets filled with the suggestions for the possible users you might mean:
jQuery(document).ready(function ($) {
// Enable multicomplete on selected inputs
jQuery('.AuthorSuggest').livequery(function () {
/// Author tag token input.
var $author = $(this);
$author.keyup(function () {
if($author.val().length<1){
return;
}
$.get(gdn.url('/user/tagsearch') + "&q=" + $author.val(), function (data) {
$('#Form_MagpieFeeds-dot-FeedOption-dot-UserID')
.find('option')
.remove()
.end();
data = JSON.parse(data);
for (var i = 0; i < data.length && i<10; i++) {
$('#Form_MagpieFeeds-dot-FeedOption-dot-UserID').append($("<option></option>")
.attr("value", data[i].id)
.text(data[i].name));
}
});
});
});
});
@vrijvlinder said:
After you disable plugins, they should automatically remove the settings saved in the config.php for that plugin, but some do not remove that data.
What event should you handle to detect that your plugin is getting disabled?
And I guess that you should then just call removeFromConfig("Plugins.MyPlugin") to get rid of everything?
If your plugin has a method onDisable() it will be called automatically when plugin is disabled.
Most plugins do not remove anything when they are disabled. If you have more complex settings, I wouldn't do it anyway. The effort to restore such settings isn't worth the benefit.
@vrijvlinder said:
After you disable plugins, they should automatically remove the settings saved in the config.php for that plugin, but some do not remove that data.
What event should you handle to detect that your plugin is getting disabled?
And I guess that you should then just call removeFromConfig("Plugins.MyPlugin") to get rid of everything?
My opinion, it is good for removing routes, but I think it is a mistake to remove most other plugin settings if something is disabled, just a pain in the neck to reset everything is you temporarily disable things and want to re-enable.
then it is a slippery slope with attempting to remove database columns.
lets say you try Yaga and decide not to use it, you have 5 extra tables created, columns in other tables, etc , etc.
it would be a mistake to automatically remove the tables automatically, but at the same time, plugins can leave a mess.
best to create a test forum environment first, and then install a plugin or app, decide whether you want to install in live environment, much much cleaner, regarding database, backups, and junk. You don't pollute your live setup that way.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
@Caylus said:
removeFromConfig("Plugins.MyPlugin") to get rid of everything?
No, stay away from that one, unless you want to accidentally delete all of your plugins.
This function was available in 2.0 from the dashboard you could delete plugins after disabling. Or even before disabling… but it had deleterious effects, such as deleting the entire plugins folder for some strange reason.
onDisable() is a safer bet but only to remove settings or routes. I do not trust this much since I was one of the victims of plugin folder rogue deletion … I just erase them by hand from the config.php if necessary.
I guess there is some confusion: removeFromConfig is harmless. There once has been an option to delete plugins and that was no good idea. Deleting config lines with removeFromConfig is save.
I'm simply not removing config settings when my plugin gets disabled anymore.
You guys were right that it would be very annoying to have to recreate all the settings again after you temporarely switch the plugin off and on again.
Comments
Ah, because you guys shared such clear information I didn't actually think of posting my solution, sorry
The relevant part of my code:
I tried both creating a view (Bot/Views/settings.php), and creating a settings page with configuration module (which is currently commented out).
$PluginInfo['Bot'] = array( 'Name' => 'Bot', 'Description' => 'A bot.', 'Version' => '1.0', 'Author' => "Your Name", 'AuthorEmail' => 'you@yourdomain.com', 'AuthorUrl' => 'http://yourdomain.com', 'MobileFriendly' => TRUE, 'SettingsPermission' => 'Garden.Moderation.Manage', 'SettingsUrl' => '/settings/Bot' ); class Bot extends Gdn_Plugin { public function SettingsController_Bot_Create($Sender) { /*$Sender->Permission('Garden.Settings.Manage'); $Sender->SetData('Title', T('Your Plugins Settings')); $Sender->AddSideMenu('dashboard/settings/plugins'); $Conf = new ConfigurationModule($Sender); $Conf->Initialize(array( 'Plugin.Bot.Username' => array( 'Control' => 'textbox', 'LabelCode' => T('Enter username'), 'Default' => c('Plugin.Bot.Username'), 'Options' => array('maxlength' => '20') ) )); $Conf->RenderAll();*/ $Sender->Render($this->GetView('settings.php')); } public function Base_GetAppSettingsMenuItems_Handler($Sender) { $Menu = $Sender->EventArguments['SideMenu']; $Menu->AddItem('Forum', T('Forum')); $Menu->AddLink('Forum', T('Bot'), '/settings/Bot', 'Garden.Settings.Manage'); }Thanks again for your help guys!
If you like to let the user be chosen by his username, I would recommend that you look at the plugin AuthorSelector. You need to include the js file
jquery.tokeninput.jsand a custom snippet of js. You can use authorselect.js if you give your input box the class "MultiComplete".Hey thanks R_J!
I couldn't get jquery.tokeninput.js to work, sadly. I still don't understand why
But at least it enabled me to write this snippet.
Now you can start typing an username and a dropdown box gets filled with the suggestions for the possible users you might mean:
jQuery(document).ready(function ($) { // Enable multicomplete on selected inputs jQuery('.AuthorSuggest').livequery(function () { /// Author tag token input. var $author = $(this); $author.keyup(function () { if($author.val().length<1){ return; } $.get(gdn.url('/user/tagsearch') + "&q=" + $author.val(), function (data) { $('#Form_MagpieFeeds-dot-FeedOption-dot-UserID') .find('option') .remove() .end(); data = JSON.parse(data); for (var i = 0; i < data.length && i<10; i++) { $('#Form_MagpieFeeds-dot-FeedOption-dot-UserID').append($("<option></option>") .attr("value", data[i].id) .text(data[i].name)); } }); }); }); });What event should you handle to detect that your plugin is getting disabled?
And I guess that you should then just call removeFromConfig("Plugins.MyPlugin") to get rid of everything?
Thanks again for the help guys!
If your plugin has a method
onDisable()it will be called automatically when plugin is disabled.Most plugins do not remove anything when they are disabled. If you have more complex settings, I wouldn't do it anyway. The effort to restore such settings isn't worth the benefit.
https://github.com/vanilla/vanilla/search?utf8=✓&q=ondisable
My opinion, it is good for removing routes, but I think it is a mistake to remove most other plugin settings if something is disabled, just a pain in the neck to reset everything is you temporarily disable things and want to re-enable.
then it is a slippery slope with attempting to remove database columns.
lets say you try Yaga and decide not to use it, you have 5 extra tables created, columns in other tables, etc , etc.
it would be a mistake to automatically remove the tables automatically, but at the same time, plugins can leave a mess.
best to create a test forum environment first, and then install a plugin or app, decide whether you want to install in live environment, much much cleaner, regarding database, backups, and junk. You don't pollute your live setup that way.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
No, stay away from that one, unless you want to accidentally delete all of your plugins.
This function was available in 2.0 from the dashboard you could delete plugins after disabling. Or even before disabling… but it had deleterious effects, such as deleting the entire plugins folder for some strange reason.
onDisable() is a safer bet but only to remove settings or routes. I do not trust this much since I was one of the victims of plugin folder rogue deletion … I just erase them by hand from the config.php if necessary.
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
Thanks! I'll stay away from that then.
I guess there is some confusion: removeFromConfig is harmless. There once has been an option to delete plugins and that was no good idea. Deleting config lines with removeFromConfig is save.
Oh yeah, sorry for phrasing that ambiguously.
I'm simply not removing config settings when my plugin gets disabled anymore.
You guys were right that it would be very annoying to have to recreate all the settings again after you temporarely switch the plugin off and on again.