Best Of
Re: @Developers: Functions to Avoid...
The idea that removing a function call that calls the singleton method anyway, would provide any significant performance boost make no sense, so not sure what is meant by 'optimising'. There could be other reasons such as reducing and rationalising the code base to focus on core objectives. Fair enough.
@RJ I agree about val it is a convenience method that I'm guilty of using a little too much. Bad habit.
I'm all for improvement, however the lack of engagement with addon developers is just goign to mean they less inclined to maintain them, they will just move on and more ad more of them will be broken. Very few of us have time to completely re-factor them every new release. Breaking changes may have to be made, but sometime breaking changes aren't made to improve anything and are just code idealism, and that can be frustrating.
Perhaps it is to make it easier for the core team and easier for developers, that is fine, but unless this is communicated what is required, addon developer aren't going respond in time, if at all. Right now there is no relationship between core releases and addon releases. Merely the implication exists.
Also if the core team are goign to make sacrifices for the greater good then addon developer should be able to too. I want to cut down on what I wish to support, becuase they are either obsolete, my time is better focus on the ones that matter.
@Developers: Functions to Avoid...
Don't use c() and t() because they will be deprecated:
https://github.com/vanilla/vanilla/issues/7688
https://github.com/vanilla/vanilla/issues/7687
Instead use the longer form Gdn::config() and Gdn::translate().
Something which might not been known, but has been said long before: avoiding val() is a good idea, too. Not because it will be deprecated (soon :shrug:), but simply because it is not needed oftentimes. If you now the type of the variable simply use the correct code to get the arrays element/objects property. Right now val() is purged out of Vanilla from all the places where it is possible:
https://github.com/vanilla/vanilla/pull/7689
By the way: I don't know such things because someone tells me, I simply follow what's going on on the GitHub repo. If you want to stay up to date, I recommend watching the repo 
Re: What is the right way to use our custom config file?
I'd also suggest reading on Gdn::get() and Gdn::set() in https://docs.vanillaforums.com/developer/framework/helpers/
Re: How to upgrade from 2.0.18 to 2.6?
The importer is not for updating, it simply wouldn't work.
Although I like the idea of a video, it sounds simpler than this would be. It would only help those people who have no additional plugins running.
If "Do you have people who do this" means if there is some kind of staff doing that, than no, there is no one like that. Here are "only" volunteers. But just recently I did an upgrade with someone who seeked for help like you do. And just like you he was coming from a one click installer Vanilla version.
If you can grant me a few things, I can support you:
1. You have a working backup of your files and database.
2. An hour downtime will be no problem for your forum.
3. You do not have custom plugins (or at least no complex ones) and you are fine if some of this functionality isn't available any more after the upgrade.
4. Don't blame me for anything!
Let me explain something on that:
Working Backup
Having a backup when you are not sure how to restore the data is better than not having a backup, but it nevertheless is a disaster if you need several days to recreate your forum only because you have to find help for your backup. No matter how this story continues, make sure you have a backup of all files and of the database and you can restore them in minutes.
Downtime
If you are a pro, the downtime will only take a few minutes. But you would need to have a mirror of you forum where you can simulate the upgrade and automate all the steps needed to do the upgrade so that you can do the upgrade of the live environment really quick.
Please don't be offended, but I do not have the impression that you have managed to create a development environment with your forums data.
This is not a real problem if it is okay for you, that every testing will result in a downtime for the time it takes to test and to restore data.
Customizations
Several plugins have been updated to work with versions higher than 2.0.18 and some have not. So if you use a plugin, it might be that for Vanilla 2.6 this plugins isn't available any more.
Responsibility
I would say that I'm a good choice for someone to update a Vanilla version, but there are a lot of things that can go wrong and I might not be able to help. That's why you should have a backup. If I create a lot of mess, you would be able to restore the forum and the only harm taken would be the waste of time. That's why a backup gives me a good feeling, too.
Upgrading can be done by unzipping the current version into the old installation, but it requires additional steps:
1. Check for new versions of your theme and plugins
2. Block access to your forum
3. Deactivate all plugins and return to the default theme
4. Unzip the new version of Vanilla, the theme and the plugins to the correct places
5. Delete the htmlawed and the tagging plugin
6. Delete /applications/vanilla/controllers/class.settingscontroller.php
7. Delete every file (not folders, only files!) in /cache
8. Visit yourforum.com/utility/update and yourforum.com/utility/structure several times, the order doesn't matter.
9. Repeat step 7 and 8 several times
10. Visit your forum to see if it looks good. If not, back to step 7!
11. If it looks good, activate all plugins and themes one by one and visit your forum after each time that you have enabled a plugin to check that nothing is broken.
Oh, I forgot two steps to begin with:
- Make a backup!!!
- Make sure the system requirements are met!
If you are interested in my help, please write me a message and give some info:
1. The url so that I can check how much cutomizations I can see
2. If you have a virtual private server or a hosting package. In the end I'm interested if you have shell access to the server
Re: VanillaAPP - A native App for Vanillaforums
Hi all,
Vanilla APP now has a themeing option. Users of your forum can now change the app to their prefered colors. Our users are very happy about it. In a custom setup for your community we are able to integrate your color variations. As seen in the image below we integrated some nice gradients.
We have more in the pipe. Check it out by downloading the demo app on the iOS app store.
Best, phreak
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
