Best Of
Re: Vanilla 2021.009 no categories found
Okay so wow, some huge revelations here and @R_J you are amazing with your help. Even though a brand new version of 2021.012 looked like it was working with String values returned form the database it was NOT working!! I WAS WRONG (I can admit when I am wrong) I didn't even notice certain thing were not there like my user Icon was not showing up, there was no way to log off... And after adding custom permissions they were not being followed as you suspected @R_J . So after trying to figure out WTF was going on with the string thing and talking to my hosting provider they said they have no servers running MySQL 8.0 so that was not an option. After doing research as to how others fixed this with the 5.7 version of MySQL I realized they kept saying what @R_J was saying was that you need to be using the MySQLnd driver. I have cPanel on my server and this option was checked and in a phpinfo() it said it was installed. What I did not realize is that it was not using it! you cannot use PDO MySQL &PDO MySQLnd at the same time (Obviously). Because my cPanel options for PHP settings are in alphabetical order I figured all these settings would be under P for PDO but fond this little reply from someone else in an article that mention cPanel has this setting under the N section for ND (go figure) So I disabled pdo_mysql and then enabled 'nd_pdo_mysql' & 'mysqlnd' once these settings took place. I ran my test code again and now it was returning INT values form the database. (YEAH). I also tested with @R_Js test plugin, it was now also returning INT values (Success). I loaded the site and everything is now functional!
To any users before you do the update please check using @R_Js plugin to see if your server is returning STRING values or INT values. If your database is returning STRING values you will have to fix this BEFORE upgrading. If the returned values are STRING then you will have to update to use mysqlnd. For every user that will be different based on your server for cPapnel do the following:
This will ensure you are using MySQLnd and then run the test plugin again and you shoudl see INT values returned. I hope this helps others. I am going to do the update again and see if I run into issues this time!
MrCaspan
Vanilla 2021.011 is now available
Today marks the official release of Vanilla 2021.011.
There have been some important changes to Vanilla since Vanilla 3.0. They've been stated in recent release posts, but I'll echo them here:
- Vanilla requires at least PHP 7.2. Future versions of Vanilla will require PHP 7.4+.
- MySQL 5.7+ is required.
- 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 will result in your full-text database indexes being lost.
There's a long change log of fixes and features, spread across the RCs and recent "gold" releases. If you're curious, you can follow them:
Last, but not least, there's Vanilla 2021.011! You can checkout its change log and download the pre-built package, over on GitHub.
This is a major upgrade from 3.3. Please follow our upgrading guide. If you experience any issues, please post specifics (exact error messages, screenshots, etc.).
dbarbier
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
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
A guide to ... JSON could not be converted into quill operations
Vanilla 2.8 (supposed issue)
PHP version or Server type/config seems to be irrelevant
file location vanilla-core-2-8/library/Vanilla/Formatting/Quill/Parser.php
/**
* Attempt to convert a JSON string into an array of operations.
*
* @param string $json
*
* @return array
* @throws FormattingException If valid operations could not be produced.
*/
public static function jsonToOperations(string $json): array {
$operations = json_decode($json, true);
if (json_last_error() !== JSON_ERROR_NONE || !is_array($operations)) {
throw new FormattingException("JSON could not be converted into quill operations.\n $json");
}
return $operations;
}
A Guide to Probably Help Others
2.8 introduced a new editor, and with it a new editor format.
On Fresh install or upgrade of existing forum one/two very important settings in your /conf/config.php will change to
$Configuration['Garden']['InputFormatter'] = 'Rich'; //Html, Markdown $Configuration['Garden']['MobileInputFormatter'] = 'Rich'; //Html, Markdown
That is the same settings now in /conf/config-defaults.php
What the above means is that, your new default format is now 'Rich'. (THIS IS SOMETHING TO EASILY FORGET OR NOT REALIZE)
10 to 1, your existing discussions already have a format such as (Html, WYSIWYG, Markdown, BBCode, Text), these will have no problem because they will not evoke Rich Editor, and have nothing to do with the Rich Format.
- BUT new discussions will take the "Rich" format setting, as per your default setting. Now, you must be using an editor that can send the required valid JSON to the DataBase. Or else you will get the error we are talking about.
- If you change InputFormatter to Html or Markdown in /conf/config.php . The entire line is gutted when you disable Rich Editor. And therefore InputFormatter setting will be derived from /conf/config-defaults.php which has it as "Rich".
- And so, all editors (Rich Editor being disabled) you use now will fail when creating new discussions because they cannot produce the required valid JSON.
- If you have InputFormatter set to anything but "Rich", and you re-enable the Rich Editor, beware, that InputFormatter will be reset to "Rich". If you disable this Rich Editor, be sure to reset that InputFormatter setting in config.php, and best to reset that in config-defaults.php as well.
- If you will not be using the Rich-Editor plugin, disable it, delete its folder, and you must explicitly set the InputFormatter in both config.php and config-defaults.php
Hope this helps some poor traveler.
Cheers.
YAGA reactions - What da ya(ga) need?
Hi everybody,
As promised in another thread I am currently working on a new library of YAGA reaction icons. After the amazing code contributions to YAGA by @Bleistivt with help from @R_J and @pioc34 as well as others... it is now about time to give the look of reactions a fresher appearance.
This is the old icon table that - especially on retina displays - appears to be blurry and uncrisp.
I started working on new SVG icon set to integrate into YAGA. They will be able to scale to any dimension as they are SVGs. So far I cover some basics and before I come to more special icons I would like to ask the community what could be smart and relevant reactions making sense to many forums.
So first of all, what do you think of it and more importantly which reactions should I create that could be utilized by many communities? 🤔
Please provide one or two sentences of little explanation so I can understand the reaction you propose.
➡️ Current YAGA version can always be found here: https://vanillaskins.com/plugins.html#yaga
Thanx to everyone,
phreak
phreak
Re: How do I insert an image into a Discussion
You do not have "pretty urls" enabled. But that's a vanilla requirement. You should have a .htaccess.dist file in your forum root. Rename it to .htaccess and reload the forums home page. It should appear without the &p= stuff
R_J
Corona-Pandemic - Free plugins for social communities
Hi all,
We from VanillaSkins.com would like to give out our paid plugins to communities who are dealing with topics that are relevant for social stability.
The current corona pandemic is spreading rapidly in Europe. It already affects major industries and not only airports and local shops are ordered to shut down, also critical infrastructure like hospitals and organizations experience disorders. Reports are coming in that internet infrastructure like MS teams, Zoom or Discord are down repeatedly.
Due to the fact that forums like Vanillaforums OS are silos of experience and opinions and can relatively easily be setup on smaller infrastructure, we are offering our paid plugins for free to communities that are directly connected to important parts of our lives and society.
So if you run a community on psychological health, or you manage a forum of an NGO dealing with climate change, a forum on teaching children who can't go to school or you are a part of farmers collective exchanging growth cycles of crops... please contact me if any of our plugins would provide help to your community.
This shall not be empty words seen as a marketing opportunity. Problems surrounding the corona virus got pretty real in the last days events in Europe. I myself manage multiple pregnancy and birth communities and expecting mothers are afraid to go to the hospitals, fathers are not let into delivery rooms and birth clinics are closing. As mothers are asking for home birth opportunities we currently connect midwifes specialized in that field with them. So probably there is an opportunity for your community to help in this situation too. Think about it.
Best regards and keep save,
phreak
phreak
Running vanilla from docker in production
I've been using Vanilla for about 5 years, and have developed a maintenance process along the way that has broken down. My goal was to version control our setup (customisations, theme, plugins), and allow for automated deployments like the rest of our stack. I did this by forking the repo and adding to it: for plugins that were on GitHub, I added them as submodules; when they weren't on GitHub, I added their contents to our repo.
This worked for the most part, but upgrading the forums was always a bit of a pain, as we had to rebase and deal with any merge conflicts. We now have a huge number of merge conflicts, to the point that I'd like to start over and make a better setup.
The goal is to create a version controlled forum setup, with reproducible builds, that can run on an ephemeral filesystem (even heroku) so we can load balance it and even blow it away and reconstruct it if necessary. The twelve-factor app provides some background and general principles for this.
To do this, I figure I'll need to:
- Start from a specific Vanilla release: either a distributed package (zip) or the GitHub codebase (in which case I'd need to run composer).
- Fill in
config.phpwith settings and secrets, without putting secrets into version control. - Pull in our theme, either from a separate git repo or from a directory within this repo, and move it to the
themesdirectory of the Vanilla codebase. - Do the same for 10+ plugins, some of which are on GitHub, others which are just .zip files on the addons website.
- Set
conf,cache, anduploadsto be writable by PHP. - Somehow make
uploadsa separate volume (like S3) so it can be shared across multiple instances and can persist (even be backed up).
I've started implementing this in a Dockerfile. You can see my progress so far at this repo.
Where I need help
1. config.php
I'm having some trouble with config.php because Vanilla writes to it when an admin makes a change in the admin dashboard: it replaces getenv(...) with the plaintext value. Therefore, if you want to commit any changes made in the dashboard back to source control (say, by mounting config.php as a volume and then making the changes), you'd be committing secrets unless you remember to go back in and change them back to getenv . Solutions to this I've thought of so far are: (a) make it read-only, so the application cannot change it, or (b) consider it a secrets file, outside of source control. But then how would you do an automated deployment? Is there a way to stop Vanilla from writing to config.php ? I would think the database would be better suited for some of these settings, no?
2. Pulling in the theme and plugins
The simplest approach here is for the Dockerfile to just curl and unzip the theme and plugins. I can either put them in the appropriate place in the Vanilla codebase, or symlink them; it doesn't make much difference, I don't think. But it starts to feel like the job of a dependency manager. I could use composer here, but I'd have to either move the installed directory or symlink it to the appropriate place, and I don't think composer can do that, can it? Does anything else come to mind here?
Let me know if there's been any prior work on this, or if anyone wants to collaborate. I'm sure there's ways we can make the repo generic.
