I'm not 100% sure myself. We've definitely had some releases that got delayed too much and that certainly doesn't help the community. It's interesting though because development of Vanilla has never been more active.
We've almost tripled the size of our developer team in the past year, and gotten a lot more productive on top of that.
I will note though, that just because the community itself has less comments doesn't mean Vanilla is less used. Thousands of previous threads and Github issues, as well as much better documentation mean it can be far easier to get assistance with a lot of issues with a quick google search. The most popular categories here are the help categories by far so that's part of it too.
Use this code to upload the video
<iframe width="420" height="315"
src="https://www.youtube.com/embed/tgbNymZ7vqY">
</iframe>
You don't. The whole point of that file is that Vanilla needs a way to add CSS for new platform features, but the bootstrap3 theme (which along with its derivatives was very popular before keystone) did not use style.css.
When we added Category Following & Rich Editor we needed a way to add additional core CSS that would apply into every theme.
We have a new strategy going forward, but that's why style-compat is there.
Why do you want to remove it anyways?
I'm planning on migrating my forum over to a new host very soon, and figured that while I'm at it, I should look into upgrading it. I'm wondering if it's even possible to upgrade to the newest version (2.6) or not, considering mine is very old. As of now, I have everything setup perfectly, in the sense that plugins work cohesively and error-free, and i'm sure most of these plugins won't be able to be transferred over, but that's fine, and I'll work around it. Also, since I'm not having any errors at all, maybe it's just best to keep it the way it is? Any feedback is appreciated, thanks!
Rich Editor saw a number of enhancements in this release.
New paragraph level formatting menu
We've added a new paragraph level formatting menu in order to surface more formatting options.
Currently it is broken down into 4 categories.
New Rich Editor formats
Along with the paragraph formatting menu, we've added support for
Improved Pasting Robustness
This iteration of Rich Editor see much improved ability to paste content into the editor.
The following may now be pasted from other web pages
Markdown Macros
Rich editor now has support for markdown based macros. Try out standard markdown input syntax and watch as it is transformed into your Rich Post.
Other
It is now possible to limit maximum image upload dimensions through and enhanced dashboard posting page. Any images uploaded above this limit will be resized (while preserving aspect ratio) to fit within the configured dimensions.
These dimensions will be respected in Rich Editor, Advanced Editor, and the /api/v2/media endpoint.
The keystone header on desktop now contains core & contextual navigation items. Additionally these items can be found on mobile devices by opening the navigation menu.
Other
Blocking Script Tags
By default Vanilla blocks a page from rendering until most of its javascript is loaded. This is not considered best practice, because it negatively impacts user’s page load times. Search engines like google penalize sites that do this.
Site’s may now opt-in to better behaviour here and load all scripts after the main document loads. This can be done by setting the configuration value.
$Configuration['Feature']['DeferredLegacyScripts']['Enabled'] = true;
or in JSON (Vanilla console)
"Feature": {
"DeferredLegacyScripts": {
"Enabled": false
}
}
If this is done properly all scripts in the of the page should have the defer attribute set.
This can lead to large increases in score on google’s page-speed index as well improved load times for users, especially on mobile.
Warning: This may not be compatible with certain custom Pockets or custom themes. Please test on staging environments first.
Due to the fact that Google is sunsetting Google+ Sign In method we are adding Google Sign In. Forums that are using Google+ now are strongly recommended to create an OpenID OAuth 2.0 application at Google and turn on the Google Sign In plugin.
For more information about the user authentication workflow that is being implemented please read this documentation on Google.com. For instructions on how to set up the plugin see Vanilla user docs for Google Sign In
Set the canonical URL of a discussion
PUT /api/v2/discussions/:id/canonical-urlDELETE /api/v2/discussions/:id/canonical-urlExpand accepted answer IDs
The GET /api/v2/discussions/:id endpoint now offers an expand parameter acceptedAnswers. When set the commentID & rendered text of the accepted answer will be included in the response.
Current user endpoints
GET /api/v2/users/meGET /api/v2/users/me-countsThese 2 endpoints may be used to fetch information about the currently signed in user.
Record a page view
POST /api/v2/tickNote: This fix is also present in the 2.8.4 release.
It has been brought to our attention that our file system permissions were far to open in our open source releases. These concerns were initially dismissed because in our version control repository and on all of our infrastructure the permissions were correct.
Thanks to the insistence of @R_J I discovered a bug in our OSS release build tool that reset all of the file permissions to 777 (very dangerous).
Starting in this release file system permissions are essentially 755 for directories and 644 for files.
Discussions/Comments
Categories
Embedded Comments
Twitter SSO
Accessibility
Profile
You're a legend @murrayZ .... THANKYOU.
For what its' worth, this problem still exists in 3.0.1.
I created a PR on vanilla's github.
pinchies
You can download a theme from here and it will be a zip file.
It can be best explained by using a name, e.g. Groovy.
The file needs to be unzipped to your /themes folder. While normally simple unzipping is enough, you can check the following three things to be sure that the unzipping was correct:
/themes/Groovyabout.php or addon.json => /themes/Groovy/about.php. If both files exist, the addon.json is the important file!$ThemeInfo['Groovy'] =... or if there is a file addon.json, you need to find a line like "key": "Groovy",The folder must be named exactly like the text you find in addon.json or about.php: "Groovy". If your zip file has been extracted to "Groovy", but in the addon.json/about.php you see it is spelled all lower case "groovy", you have to rename the folder.
If you cannot see the theme in the dasboard, delete /cache/theme-index.php and if there is a file /cache/theme/groovy.php or /cache/theme/Groovy.php, which is not probable, delete that, too
R_J
You mean ask the client's IT guy to drop everything so he can figure out how to do that and then do it and then wait while I go through hundreds or thousands of posts (assuming I can search the database for posts containing BR tags) and analyze every single BR tag to determine whether it's needed and remove the ones that aren't, and then replace the entire archive in the hope that everything will go without a hitch?
Yeesh.
browninc
15 minutes to do a database dump, clean up, and reimport.
