Best Of
Vanilla 2021.003 RC2 is now available
Today, on the 16th anniversary of this community, we're introducing Vanilla 2021.003 RC2, which is the sequel to Vanilla 4.0 RC1.
This version number is sure to confuse some folks, so let me take a minute to explain. In an effort to streamline our OSS releases, we're going to try bringing their version numbers inline with what we use in our hosted product. Approximately once every two weeks, we crank out a new hosted release and version it based on the current year along with its sequence in the releases for that year. Instead of trying to translate between the two versions (e.g. 4.0 might internally mean 2021.003, while 4.0.1 could internally be 2021.004), they'll each have the same versioning.
You've also probably noticed this is the second release candidate for the new version. The plan is to try this out for a couple weeks and, barring any reports of catastrophic breakage from the community, formally releasing it as the next official version of Vanilla.
Same as RC1, there are some warnings and considerations I'll repeat here:
- This is an RC (release candidate). It is not intended for use in production environments. It is pre-release software. Install it in some kind of sandbox and go nuts, but avoid overwriting your existing Vanilla installs. Once we're confident in Vanilla 2021.003 on open-source community sites, we'll drop a production-ready release. Future updates probably won't need an RC cycle, but given the length of time since the last release, it seems prudent.
- Vanilla 2021.003 requires at least PHP 7.2. It's also the last version that'll support PHP 7.2. Future versions of Vanilla will require PHP 7.4+.
- MySQL 5.7+ is required, starting with Vanilla 2021.003.
- Full-text indexes have been disabled by default. You can enable them by adding a
Database.FullTextIndexingkey to your config and setting it totrue. Failure to do this before upgrading to Vanilla 2021.003 will result in your full-text database indexes being lost.
If you're still feeling bold, you can checkout the changelog and download Vanilla 2021.003 RC2 over on GitHub. You'll find a pre-built package under "Assets".
Re: Vanilla 4.0 RC1 is now available
I have been trying it out all morning, fixing plugins. I think I have reported everything I found now. The update itself was smooth. A quick warning for users of the bundled Profile extender plugin however: There is a bug in this release candidate that causes the profile fields to come up empty on the profile/edit view. Users who save their profile will clear out those fields, so better hold off using it in production if you depend on this plugin.
Vanilla 4.0 RC1 is now available
It's been a while, so let's get right to it: today marks the availability of Vanilla 4.0 RC1.
There are more than 900 fixes and features in this release. For now, I won't attempt to list them all here. If you're dying to know, you can checkout the current change log over on GitHub: Vanilla 4.0 RC1 change log. You may also download a built copy of Vanilla from that page (ProTip: search for "vanilla-4.0-rc1.zip", under Assets). For now, I'll hit some key points:
- This is an RC (release candidate). It is not intended for use in production environments. It is pre-release software. Install it in some kind of sandbox and go nuts, but avoid overwriting your existing Vanilla installs. Once we're confident in Vanilla 4.0 on open-source community sites, we'll drop a production-ready release. Future updates probably won't need an RC cycle, but given the length of time since the last release, it seems prudent.
- Vanilla 4.0 requires at least PHP 7.2. It's also the last version that'll support PHP 7.2. Future versions of Vanilla (5.0+) will require PHP 7.4+.
- MySQL 5.7+ is required, starting with Vanilla 4.0.
- Full-text indexes have been disabled by default. You can enable them by adding a
Database.FullTextIndexingkey to your config and setting it totrue. Failure to do this before upgrading to Vanilla 4.0 will result in your full-text database indexes being dropped. - The Reactions addon has made its way to the open-source project.
initvector
Brainstorming on the sense of a OS powered community forum
All that talking about self-building Vanilla from the sources, the lack of "official" support and some personal annoyances made me think about better alternatives.
But at first: which annoyances are there from my side?
- I hate searching for the correct config debug setting if people ask about "Whoops" errors
- I hate telling people which of the features in this forum are not available to them
- I hate telling people that I don't see any claims for official support ;-)
- I hate seeing releases made only annually
- I hate having outdated addons available although there are newer versions on GitHub
- I hate the addons sections layout
- I hate seeing an Activity log full of spammer
- I hate seeing a meaningless "Best of" page
- I absolutely hate the bitchy "Rich" Editor!
Do I see better alternatives? Yes, for each and every single point in my list. Some of them would be quick wins, some of them would require much more work.
- Auto Answering (quick win)
Do you know about that great bot plugin from Linc? Let's see if it still works: ^5 @Vorgo
Why not make him listen for "Whoops"? "@Vorgo Whoops" should cause the bot to give a detailed explanation and what the best next steps are
2. False promises (quick win)
Showing people features that aren't available might be a way to acquire new customers, but most of the time it simply is disappointing for curious people. Features not available to the open source version shouldn't be available.
3. Big one, I skip it for now and make it the last point
4. Community releases (quick win)
Anyone can create a "release"! I did it today by running the build script. I made a test install, found one thing to fix, but after that I could have uploaded it so that even the people who do not feel like they would be able to run the build process can profit from my work. All that is needed is some work from somebody who has time, ability and credibility
5. & 6. Addon section rework (major change)
The addons section gets no love and I think that's for a reason. From my point of view it needs a complete reboot. Strict rules for all new plugins enforcing standards and most important: no uploads. Only links to GitHub repos from which all info about current version, last update time and so on will dynamically be fetched and certainly you will find a download link there. I love how it looks at ProcessWire.
I would even go one step further and only allow the plugin repos README.md as description.
But that alone would fill a discussion. I just wanted to share my vision
7. Profile Spammers (might be easy, not sure)
Two of the profile fields here allow links. That's rubbish, but even if I allow links, I would vote for a short profile for new users. Only allow normal profiles for users with somehow defined "reputation". Yes I know this is very vague, but my preferred solution would require a new plugin which allows a community to build up a "trusted" user base.
By the way: the biggest Activity log "spammer" is the minion which is somewhat awkward and has no benefit at all.
8. "Best of..." (quick win)
As of know the best post here consists of four letters "Done". As long as there is no flood of posts where it is hard to make out the good posts, that feature is useless. Just switch it off.
9. Bitchy, glitchy "Rich" Editor (quick win)
It has been too early. That thing is not production reads. Please release us. Replace it with Advanced Editor.
And now the last one which is the main reason for starting this discussion
3. "Official" Support Forum
This is the official support forum run and owned by Vanilla Inc., run on their official domain - but it is only for the open source version. I understand why everybody expects support by the official developers here. But that only leads to disappointment. Disappointment also comes from people who see this forum and get something different when they install their own forum.
Personally I don't see a benefit of the OS support forum being hosted by Vanilla Inc.
It just came to my mind that it would make much more sense to run a open source Vanilla forum for the OS support.
People would really see what they get, because their should be a discussion telling which plugins the page is using.
We as a community could influence in more detail how our community would work (e.g. there are some of you amongst us which I would have already given moderator rights)
I would get rid of bitchy "Rich" Editor 😎
The downsides are, that it would cost money and time. Time for setting it up, time for keeping the forum up to date, time for testing the most current master branch, time to implement a better addon section. And last but not least: I think it might be against the will of Vanilla Inc. which I could understand in some terms.
Some of my points from above could be done without creating a second inofficial official support forum. It would be sad to loose reactions, though. Keeping them and creating a "@Vorgo YAGA" might be a good compromise.
Maybe this just came out of frustration: I never imagined I would ever experience "lockdown" and "curfew" in my own country and I have the impression, it has a bad influence on my temper.
But anyway: I took the time to write my frustration down and I am eager to read your opinions on that - the more the better!
R_J
Everything is wrong with this theme
Dear Vanilla Team,
I am simply breathless... it’s absurd above all things. How would someone release such a theme to an official forum?
I would consider firing this person.
phreak
Re: What Happened to the Ability to Set Font Color in a Post?
There has been a team decision that this is no important feature and would even be bad for accessibility. Sure, if you choose light gray on white... I once tried to create a plugin which would have allowed using a font color bbcode but the way this is implemented made me give up because I would have had to replace to much of the core functionality
R_J
Re: What Happened to the Ability to Set Font Color in a Post?
Rich Editor vs what Post Format you used before perhaps
https://success.vanillaforums.com/kb/articles/13-rich-editor
Kaspar
Re: Has Vanilla development gone private?
Thanks or the answer @charrondev
I really appreciate you shedding some light on this. I am sorry that a lot of the community management burden of seems to fall on you as you are the only core member still actively responding here.
With the danger of going a little off topic let me explain how I feel about this recent change and how I think it could be leveraged to improve the Vanilla OS environment for everyone.
For the last years I experienced somewhat of a Vanilla fatigue ("burnout" being a too strong word for me). This is also why I am not as active in this forum as I used to be. It can be boiled down to two reasons: The pull request process and the inefficiencies of this forum.
The Pull Request Process
It may come to no suprise that I am (as most people here) myself a frequent user of Vanilla, both on the user and admin side. I have encouraged my users over the last 7 years to report any bugs or glitches they encounter.
Pretty much all of my open source contributions are a direct result of my users reporting bugs to me. I usually patch those for my production environment and then submit a pull request. In the last years it has become increasingly hard not having to maintain a fork of the software.
Just upgrading to the latest open source version before these are merged would introduce regressions my users would immediately notice ("haven't you fixed that some time ago?"). I had to write countless throwaway plugins containing method overrides or dirty hacks to be able to upgrade the forums.
This is not a critique of the team! I understand there are priorities and reviewing and testing code changes takes a lot of time.
I can totally understand the reasons for using a monorepo as well. Daily syncs will probably be a good substitute for regular commits in the vanilla/vanilla repo. To be clear however, there is still a loss for OS contributors. Not having the info about why something was changed, cripples the ability to track down bugs.
I am currently in the process of tracking down a bug with announcements and user-specific discussion data. I don't know if I'll be successful, but without the background information provided by pull requests, issues and git blame data, I don't think it could be done at all.
However, with the new process, I think there are also great opportunities on the horizon. Since commits in vanilla/vanilla no longer directly affects Vanillas production environment, they could all go to a "os-patches" branch that could be merged faster. Faster merges would be more encouraging for new contributors and people who need certain fixes could pull from that branch.
The Inefficiencies of This Forum
The Addon Application
The addon application has been aging very badly and I don't think it is needed very much anymore.
With a large part of the plugins being incompatible with recent versions, sorting by "most downloads" and the confidence rating become meaningless. Trying out plugins is very frustrating for new users since the majority does not work out of the box.
With most of the Vanilla created plugins soon being part of the core, the main reason, people still visit the addon repository on this site is most likely locales. But all locales should probably be included in the OS disctribution anyway. This is how most sofware seems to do it and it would eliminate the problem of having an outdated locale after updating. vanilla/locales zipped size is currently 4 MB which I don't think would be a problem to add to the standard download package.
For all user created plugins I propose a simple alternative: discussions
In my opinion, discussions are actually more suited for plugin discovery:
- New plugins will get more attention as they appear on the recent discussions page
- The discussion can be directly used for feedback: Every plugin having a discussion from the start removes the friction of creating one to ask a support question.
- With a dedicated category for plugins, they can be found using the regular search, which will likely bring up more relevant results anyway.
- This would also mean that the standard moderation and curation tools apply to plugins: New version can receive reactions and plugin threads could be closed if the plugin is unmaintained.
The only caveat I see here is the EditContentTimeout setting, which prevents a discussion starter from adding a new version to the first post. But this is also a good thing as attachment uploads can't be silently switched out that way, which will be just as secure as the current solution, if not more. However, it would require moderators to add a new version to the first post or link the comment with the attachment.
Something has gone wrong.
This is the most asked question on this site. It could be eliminated with a simple message at the top that reads something like this:
Something has gone wrong.
If you encounter this message, please edit the following value in your configuration file /conf/config.php before you ask for help:
$Configuration['Debug'] = true;
Reloading the page will show the actual error which you can add to your question.
Conclusion
I love Vanilla. I have built highly customized communities fully on Vanilla because it is a joy to develop against the framework and I believe in its future. There are many modern community solutions out there, but the value of software like Vanilla that scales and is battle-tested can't be overstated.
Since this was a little long, here is a TL;DR about the relatively cheap changes which, in my opinion, would enhance Vanillas open source environment drastically:
- A message at the top containing debug instructions
- Forum discussions for plugins in place of the addons app
- A branch "OS-fixes" on vanilla/vanilla containing community patches
- Ship the core with all locales