Best Of
Re: Still getting this PHP error [RESOLVED]
Oh no, that's not too encouraging...
Re: Prototyping custom themes for 2.5.x using XAMPP? [RESOLVED]
"key": "Godot", // Exactly the same as the resulting folder for the otherwise copied theme
I guess, that's just in your comment? Otherwise it would be invalid json.
Try clearing the addon cache. For development, I usually add this to a plugin so I don't have to clear it by hand every time I make changes to an addon.json:
public function settingscontroller_afterDisablePlugin_handler() {Gdn::addonManager()->clearCache();}
public function settingscontroller_afterEnablePlugin_handler() {Gdn::addonManager()->clearCache();}
public function settingscontroller_afterEnableTheme_handler() {Gdn::addonManager()->clearCache();}
Re: jsConnect and AutoConnect
It's posts like this one that go unanswered for two + days that reaffirm that I am in no hurry to upgrade my (delicate) SSO forums. That is my main complaint with vanilla forums.. piecemeal documentation and scattered forum responses.
Re: Transifex isn't updated
Any update on this? Still looks like the majority of locales are from November 2016.
Addon directory fixes
Hey guys,
The addon directory has some issues:
- If you go to an addon download page, the link to the author is broken (because the output of UserUrl is needlessly escaped again, even though userURL already sanatizes dangerous input).
- It completely ignores addon.json files in your zip file and it requires a PluginInfo array in your plugin file (even though that approach is deprecated). See this issue: https://github.com/vanilla/community/issues/135
- If your main class is class.Fancyplugin.php, it fails because it requires either class.FancyPlugin.plugin.php or default.php
- Plugins, applications and themes are now all addons. But there is no general addon type, so even if the addon directory would parse the addon.json file correctly, it wouldn't work because it has no type to file it under.
I think I fixed these various issues, but does someone have time to try out the fix / check the style requirements before I create a pull request?
https://github.com/Caylus/community
Re: Any plugin conversion tool available/necessary for Vanilla 2.5?
@Caylus said:
For my own use I've created this plugin:https://github.com/Caylus/PluginFixer/blob/master/class.PluginFixer.php
I'm strongly against running any automatic "fix" against the addon section though, since it's really hard to protect against all the exceptions to general rules, and odds are you break quite a few plugins by trying to fix them.
I just convert individual plugins, then I can at least test them individually to make sure they still work after my "fix".
I strongly agree that this is a better approach.
Here is my contribution for the addon.json update: https://github.com/R-J/addonjsonexporter
The plugins setting screen shows a dropdown with all available plugins and shows all internally stored plugin info keys in json format
Re: Any plugin conversion tool available/necessary for Vanilla 2.5?
For my own use I've created this plugin:
https://github.com/Caylus/PluginFixer/blob/master/class.PluginFixer.php
You download a zip file from the addon section, go to the settings page of this plugin, upload the zip file and download a "fixed" zip file.
It basically creates a addon.json file inside the zip file, and makes sure the classname is called KeyPlugin (older plugins sometimes only have a Key as name).
I'm strongly against running any automatic "fix" against the addon section though, since it's really hard to protect against all the exceptions to general rules, and odds are you break quite a few plugins by trying to fix them.
I just convert individual plugins, then I can at least test them individually to make sure they still work after my "fix".
Re: Official Feedback Thread
Of course it should be changed, but it should do by owner with update in repository.
Re: Vanilla 2.6 is coming! Are you ready?
hmmm...my biggest concern is the amount of breaking changes and where they are documented. I'm not even updating all clients to 2.5 yet.
There have been breaking changes over the years and often you find many things out by accident it can be a daunting task updating addons. Like methods with swapped round parameters claimed to be made in the name of backwards compatibility (more trying to be consistent with other methods) when in fact it is a breaking change. Instead of that a new method would be better, then you can depreciate the old one.
Lets be honest it is not the easiest framework to work on, compare to others, It is not the worst either, but development tend to be slowed down it due to consistency issues. There are conventions, but there have been a number of different ones over the years and it can be very mixed for quite similar things.
I'd also be worried about the motivation and engagement of developers, which I predict is waning. I think there is a pattern of developing pluign and not updating them. heck I don't feel motivated to to that given little time. I would like to take some of them off the repository so I can focus on what it is possible for me to support with limited time. Some of them aren't too relevant, I'd like to be able to prune those out.
I do totally understand the progress involves pain and that is necessary, but those changes need to be documented better, perhaps as momentum is picking up thing will get better. I hope that is the case. maybe there need to be a system, so developer are more prepared rather then playing catch up. it is quite daunting, I can't really blame people for moving on.
Working with client most of them are very externally minded it is all about the interface. One of the weakens of the framework is the views. We are in an era beyond basic MVC and we are morning into more dynamic front end such as angular.
You could for example have view models to dynamically drive your templates, which employ services to communicate with the controllers. On request the controller could employ the view model (which would be backward computability for old style views).
JQuery as much as I loved it over they years it is like the hand of god. It is not context based or obvious, it can come in from up hight and manipulate things, except it is often not one god but many, which can work at cross purposes.
The current view are no better or less entangled than they were under Vanilla 1.
Separation of concerns and being able to more thing around is limited except through non context based hand of god methods. Normally view model would also control the view resources too. However that could be figure out how that might work and a compromise be made
Or you could django style of template "blocks" where at these then it is at least easier to move things around. I think you also need rid you self of these informal "vanilla selectors" classes/id in order to manipulate the views as this is easily broken.
Nobody wants to override the current views for obvious reasons.
Re: pn.js
@River said:
The other thing I found in the plgins for 2.5 is that with some plugins the Settings don't show completely if there are many settings on a separate setting page in views.
You can add "usePopupSettings":false in addon.json (and I expect "UsePopupSettings" => false in PluginInfo) in order to avoid that the setting page will be opened as a popup
@Caylus said:
The docs may say that it's still supported, but that's not my experience up until now. With addon.json plugins work, without them plugins that worked fine in 2.3 fail in 2.5 (at least in my specific setup).Was fun figuring that out, I can tell you that /sarcasm.
@River said:
FWIW default.php name seems to work currently as long as Class in the plugin has Plugin in the class name withing the plugin.
Naming conventions seems to be evolving, just take a look at the vanillaconnect plugin and you will find the file 'VanillaConnectPlugin.php`. So we end up with the following options:
- default.php
- class.somename.plugin.php
- SomeNamePlugin.php
And maybe you can even name it any way you want as long as the class name is "correct"?
The correct class name for a plugin which resides in the folder /plugins/someExample would be SomeExamplePlugin
The addon.json would allow differing class names, though: "className":"SomeExamplePug" would allow you to give your plugin a ridiculous name.
