Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Rich Editor does not work on fresh Vanilla 2.8 install
P3ter
New
Hello,
I just installed Vanilla 2.8 to do some tests. It's a fresh install, not an update. It seems that Rich Editor doesn't work, the textarea simply disappear :
0
Comments
i have seen this problem as well and for me it's linked to the fact that my nginx isn't configured correctly. I've been playing around with my nginx.conf trying to get it to work and when it's misconfigured the editor disapears (in fact it seems when the page loads it's there but then disapears when loaded) or some of the icons are missing.
sorry if i can't be of more constructive help :)
It's help me, i finally got it fixed by changing my Nginx conf :
# Hardening location ~* "/\.git" { deny all; return 403; } location ~* "^/build/" { deny all; return 403; } location ~* "^/cache/" { deny all; return 403; } location ~* "^/cgi-bin/" { deny all; return 403; } location ~* "^/uploads/import/" { deny all; return 403; } location ~* "^/conf/" { deny all; return 403; } location ~* "^/tests/" { deny all; return 403; } location ~* "^/vendor/" { deny all; return 403; } location ^~ "/favicon.ico" { access_log off; log_not_found off; return 404; } # This handles all the main requests thru index.php. location ~* ^/index\.php(/|$) { fastcgi_split_path_info ^(.+\.php)(/.+)$; #try_files $fastcgi_script_name =404; set $path_info $fastcgi_path_info; fastcgi_param PATH_INFO $path_info; fastcgi_index index.php; include fastcgi.conf; fastcgi_param SCRIPT_NAME /index.php; fastcgi_param SCRIPT_FILENAME $realpath_root/index.php; fastcgi_param X_REWRITE 1; fastcgi_pass unix:/run/php/php7.2-fpm.sock; # where 'php-fpm' is the upstream, probably defined in nginx.conf } # If this is some other PHP script, disallow it by redirecting to /index.php #location ~* \.php(/|$) { # rewrite ^ /index.php$uri last; #} # Default path handling location / { try_files $uri @vanilla; } location @vanilla { rewrite ^ /index.php$uri last; }(source https://www.howtoforge.com/how-to-install-vanilla-forum-on-centos-7/#step-install-nginx-and-configure-nginx-for-matomo).
It's help me :-) I fixed that by changing my Nginx conf like this :
# Hardening location ~* "/\.git" { deny all; return 403; } location ~* "^/build/" { deny all; return 403; } location ~* "^/cache/" { deny all; return 403; } location ~* "^/cgi-bin/" { deny all; return 403; } location ~* "^/uploads/import/" { deny all; return 403; } location ~* "^/conf/" { deny all; return 403; } location ~* "^/tests/" { deny all; return 403; } location ~* "^/vendor/" { deny all; return 403; } location ^~ "/favicon.ico" { access_log off; log_not_found off; return 404; } # This handles all the main requests thru index.php. location ~* ^/index\.php(/|$) { fastcgi_split_path_info ^(.+\.php)(/.+)$; #try_files $fastcgi_script_name =404; set $path_info $fastcgi_path_info; fastcgi_param PATH_INFO $path_info; fastcgi_index index.php; include fastcgi.conf; fastcgi_param SCRIPT_NAME /index.php; fastcgi_param SCRIPT_FILENAME $realpath_root/index.php; fastcgi_param X_REWRITE 1; fastcgi_pass unix:/run/php/php7.2-fpm.sock; # where 'php-fpm' is the upstream, probably defined in nginx.conf } # If this is some other PHP script, disallow it by redirecting to /index.php #location ~* \.php(/|$) { # rewrite ^ /index.php$uri last; #} # Default path handling location / { try_files $uri @vanilla; } location @vanilla { rewrite ^ /index.php$uri last; }I've added a link to that CentOS doc in our "Backed" section of the developer docs.
Could you highlight what changed in your config?
From this example : https://docs.vanillaforums.com/developer/backend/server-nginx/
I added these four lines :
location ~* ^/index\.php(/|$) { fastcgi_split_path_info ^(.+\.php)(/.+)$; set $path_info $fastcgi_path_info; fastcgi_param PATH_INFO $path_info; fastcgi_index index.php; [...] }And commented this :
# If this is some other PHP script, disallow it by redirecting to /index.php #location ~* \.php(/|$) { # rewrite ^ /index.php$uri last; #}We should probably cleanup and unify our docker nginx config with the one in our docs.
We run a fast-cgi template like this
Unfortunently our config layout in that repo is a little bit confusing. It definitely needs a little bit of love.
That template includes the lines you added. I should note that by commenting that last line you are opening your site up to security vulnerabilities.
It puts the burden on every single one of your .php files to be secure from externally being called and creates a RCE vulnerability if a user manages to upload a file ending in .php. This may end up being possible in the future if we switch to mime-type validation instead of file name validation.
Rich Editor does not work on fresh Vanilla 2.8 install
Same here - the textarea simply disappear.
Softaculous install
Environment Information
Vanilla version: 2.8
PHP version: 7.2.14
SQL Server version: 10.1.37-MariaDB-cll-lve
Server Software: Apache
it is a fresh clean install nothing changed or added - out of the box install.
Disabled any default plugins - same.
Disabled Rich editor, enabled Adv Editor : "
JSON could not be converted into quill operations."
Disabled Adv. Editor - still : "
JSON could not be converted into quill operations."
I'm having the same problem. I'm not using Nginx. PHP version 7.3
When starting a new discussion the body box of the post editor disappears after a few seconds and it's impossible to make a post. I tried changing to Text as post format but that didn't help.
Is there anything in your javascript console? I'm guessing you're having the same issue as https://open.vanillaforums.com/discussion/36997/rich-editor-does-not-work-on-fresh-vanilla-2-8-install#latest
Javascript console shows a bunch of errors - see screenshot. I'm not a developer so I don't know how to fix these.
This is definitely a server misconfiguration issue. I’m really a bit at a loss for why both the API calls are failing and the dist files.
Could you share your nginx/Apache config?
What are missing here are *.map files and I do not find them in the folders of my installation either.
And does it really hurt not to include them? Aren't they only used for prettifying the debugger output?
Sorry I looked too quickly. The .map files are useful for debugging but are not necessary for the functioning of the site. In fact they only load when dev tools are open.
The thing is the are also necessary for nice looking stack traces which are a pre-requisite for debugging anything with the Rich Editor.
It seems the sourcemaps are being unintentionally excluded, so I'll try and make another release with them. That would enable me to assist better here.
@charrondev thanks for your reply.
The /forum/dist directory has permission of 755 - should this be changed?
Routing the API endpoints correctly - you'll need to explain how I can find this out - I'm not a developer.
nginx/Apache config - sorry, you'll need to explain where I can find this too. I'm with Siteground.
Forum URL is https://treecrops.org.nz/forum/
That helped a lot. The file permissions are fine. The issue is certainly in your web server configuration.
The API only works with the modern style of routing. This p= style has been unsupported for a couple of years now. It's supposed to be automatically enabled if the web server is setup properly. It seems to be a problem particularly on Apache and seems to be fixed and reverted every release due to various factors. Timeline here https://github.com/vanilla/vanilla/issues/7258#issuecomment-393958487
In the meantime @tcwebber could you try adding the following to your configuration and report back?
Adding
to conf/config.php gives me a 404 error any time I click away from the home forum page.
Do I need to contact my host to fix the p= style issue?
Could this have anything to do with having a separate .htaccess file as well as the .htaccess.dist file? The .htaccess was automatically created when I updated the PHP version to 7.3 and I also created a password protect for that directory temporarily.
@charrondev see comment above
I'm sorry @tcwebber I don't have much experience debugging issues with Apache. That was my hail Mary. I only know how to setup/debug nginx. Maybe another community member will be able to assist you.
I can confirm though 100% your server not rewriting URLs is the reason this is not working. The translation file is required for Rich Editor to run and it is served through an API endpoint.
The following information has been around since Vanilla 2.3 although the documentation was recently moved from the README to our public documentation:
If your forum still uses URLs including
?p=, support for this URL structure has ended. Follow these steps to switch to the simpler format:.htaccessfile provided will accomplish this. Additional setup is required on nginx and other platforms./discussions- if you see a discussions list (rather than a 404), it is likely setup correctly./conf/config.phpand find the line with$Configuration['Garden']['RewriteUrls'] = false;and delete the entire line.Your site should immediately switch to “pretty” URL paths instead of using the ‘p’ parameter. If there is a problem, re-add the line to your config and do further troubleshooting.
Could this have anything to do with having a separate .htaccess file as well as the .htaccess.dist file? The .htaccess was automatically created when I updated the PHP version to 7.3 and I also created a password protect for that directory temporarily.
That certainly is the reason. In order to have "pretty urls" you would have needed to rename htaccess.dist to .htaccess.
If you have some managing interface for your web hosting service and it changes .htaccess automatically it would be wise to search if you find a menu item to edit the .haccess file or at least be able to enter additional lines for the .htaccess file. If you do not find them, be brache and edit that file directly.
You need to insert the content of htaccess.dist at the end of the existing .htaccess file.
But if you do some server changes in the future, that new .htaccess might be overwritten. In such a case you would have to ask your hoster how to permanently change your .htaccess