Best Of
Re: Upgraded 2.0.1 to latest download but ERR_TOO_MANY_REDIRECTS
Ah just noticed you will need to uncomment the #RewriteBase /forums/ so that it is
RewriteBase /forums/
ianw5555
Re: Please help remove index.php?p= from URL
Make sure you have rewrite rules in your apache .htaccess file
# Original
# If you modify this file then change the above line to: # Modified
<IfModule mod_rewrite.c>
RewriteEngine On
# Certain hosts may require the following line.
# If vanilla is in a subfolder then you need to specify it after the /.
# (ex. You put Vanilla in /forum so change the next line to: RewriteBase /forum)
# RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php\?p=$1 [QSA,L]
</IfModule>
ianw5555
Re: What Happened to the Ability to Set Font Color in a Post?
I'm totally with you! I'm not part of any team which has anything to decide what is happening behind the Vanilla scenes. I was just reporting what I had remembered (wrongish): https://open.vanillaforums.com/discussion/comment/255288/#Comment_255288
R_J
How I fixed non working counters on Vanilla 3.3
I had with a freshly installed vanilla 3.3 version the problem, that the counters for new discussions and comments would not work, especially in nested context there was always zero for the counts that lay on deeper levels. Everything else seemed to work fine.
Since vanilla is new to me, I first suspected that I had set up something wrong, trying around with different cascades of nested discussions, moving discussions, trying different themes. Deleting test postings, deleting test users.
I also had deleted the entire cache folder when I had problems of getting the German localisation active. I was running php 7.3
I decided to start over with a clean new install. That also brought no success for my counter problem.
Then I suspected that the problem might have been caused by using a so called easy-install-app installation, provided by my web hoster 1blu.
This preconfigures some things, especially the connection to the mysql data base.
I started over all by myself now. Creating the data base and the connection by myself, installing vanilla 3.3 by running the setup.
Again the counters for subcategories didn't work in the out of the box installation.
This time I monitored the raw data in the mysql category table and saw that the counters stayed zero there. The problem was not wrong display from the data base, but not-icreasing the counts in the very beginning when creating new discussions.
This brought me on the track of older discussions about not working counters in the section of vanilla 2.8 and earlier.
The problem seemed to be that in some parts of the code that updates the category counts, a specific data type was expected but the mysql driver gave back something else. Expecting data type numeric and getting integer, or vice versa.
There were hints where to fix that in the core files by adding a type casting in the category module, but the code had changed a lot on the way to vanilla 3.3 and I already saw type castings in many lines.
I decided against modifying the code. Instead I tried to find the root cause.
Obviously the PDO sql driver, that interfaces PHP with the mysql data base, was the real cause for getting the wrong data type back.
Running php.info showed a couple of available and the active PDO driver.
The recommended mysqlnd (the native driver) was not active and not on the list of the available drivers.
Since I have a hosted account where I don't have full access to all server setup, I contacted my web hoster how to get the mysql native driver.
They told me to use the servers native long time supported PHP 7.2 that would provide the mysqlnd.
Modifying php.conf to
php_version=72-server
Running info.php showed that now the PDO driver mysqlnd was active.
From that moment on all counters worked like they should.
My problem is solved now, I just wanted to share this for people who might encounter the same problem. Don't waste too much time, try PDO driver mysqlnd.
I suspect that this kind of data type sql driver problem could cause more trouble in other plugins.
Re: SSO locked out now...
The problem here is a tricky beast.
Sweet jsConnect stores a few of its settings in the database table: GDN_UserAuthenticationProvider.
Look for these columns: AuthenticateUrl, RegisterUrl, SignInUrl, SignOutUrl.
You can delete the jsConnect plugin folder, or/and even disable it in your config.php, clear cache, update etc, but alas, the above setting remains and is still in use.
So, to prevent the loop, just empty the values in the columns above.
This feels like a bug. One that could eat you out of a few hours, if your mind is not in the right place. @charrondev what say you?
Maybe have vanilla check if jsConnect or whatever AuthenticationSchemeAlias is in use, is disabled before using those DB values?
Hope this helps someone...
Cheers!
Re: Class 'Locale' not found
I'm using Ubuntu 18, and installing php-intl solved the issue.
This looks like the version is php dependent:
but I'm pretty sure I just did
sudo apt-get install php-intl
whu606
Re: 3.3 installation difficulties
You need all the above PHP extensions before you can install the software.
Our minimum requirements are now:
- PHP 7.1 or newer. (This change to 7.2 in 2020.)
- PHP extensions mbstring (
--enable-mbstring), cURL (--with-curl), GD (on by default), and PDO (on by default). - To import into Vanilla you need MySQLi (
--with-mysqli). - To use our social plugins you need OpenSSL.
- MySQL 5.0 or newer (or Percona/MariaDB equivalent).
- MySQL strict mode disabled.
You will also need write permissions for /cache, /uploads, and /conf
ianw5555
Re: Change the content of the Terms Of Service?
You have to edit your site_core.php in locales folder (e.g. locales/vf_fr/site_core.php if you use Franch locale).
Find the strings $Definition['TermsOfService'] and $Definition['TermsOfServiceText'] , and edit the right part of each string, e.g.:
$Definition['TermsOfService'] = 'Your text';
$Definition['TermsOfServiceText'] = 'Your text';
Enjoy!
mirX
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.