Vanilla 3.0 - Release Candidate & Call for Testers

charrondev · April 2019

Back in February we announced that we were moving to use semantic versioning. That starts with this 3.0 release. As a result, this release does not contain any radical redesign or rewrite. Instead it simply represents us shipping a breaking change in a release.

With the 2.8 release we heard some feedback that the OSS community wanted additional testing for releases before we make them. It should be noted that every change that makes it into an OSS release has generally been in use on Cloud hosted service for weeks or months before they make it here. That still leaves a lot of un-tested ground. We deploy differently, we run different addons, and we run on a single operating system & version.

With this release I'm requesting anyone from the OSS community that runs a testing site or server to try the new version. We'll look out for anything major breaking, and proceed with the full release afterwards. @MichaelTyson @Shadowdare had mentioned this before, but anyone else is welcome.

Upgrade Notes

Vanilla 3.0 requires PHP 7.1 which is a change from earlier versions. We strongly recommend upgrading to PHP 7.3 as soon as possible. Many hosting plans allow a seamless transition via their control panel.
Follow the normal upgrade process, including running /utility/update.
Follow additional specific upgrade instructions if upgrading from an earlier version.
Test your plugin & theme compatibility in a safe place. This is not a final release yet so it's not recommended to run this on a production forum.

The Release

You can grab the release candidate version here. Please leave feedback in this thread or file a github issue if you can have clear reproduction steps.

charrondev · April 2019

Breaking Changes

Starting with this release Vanilla requires a minimum version of PHP 7.1. Starting with this release Vanilla's automated test suite now runs on PHP versions 7.1 - 7.3.

Deprecations

Beginning in this release the following classes are now deprecated.

\Gdn_ApplicationManager
\Gdn_ThemeManager
\Gdn_PluginManager
\Gdn_Pluggable

Additionally the following methods are now deprecated.

\Gdn::applicationManager()
\Gdn::pluginManager()
\Gdn::themeManager()
\PagerModule::rel()

If you are using any of these methods please see their inline documentation for their newer alternatives.

New Database Tables

In this release we are laying the groundwork for bringing reactions into core. The user facing feature is not a part of this release but we have created new core models and a database structure for it. As a result there are two 2 database tables that will be created.

GDN_reaction
GDN_reactionOwner

If you use a case-insensitive filesystem & the YAGA addon this will be breaking change.

Unfortunately some open source addons has taken the database table `GDN_Reaction`. This is the cause of the conflict. If you are affected here your options are essentially:

Try to organize an update to the YAGA addon.
Wait for finalization of our core reactions feature and then disable YAGA (no hard timeline).
Switch to a case-sensitive filesystem.

For people creating addons in the future I would recommend name-spacing both your classes and database tables. Was you code created as part of \Vanilla or part of the GDN_ framework? If not you should probably use a different prefix or append some additional prefix.

charrondev · April 2019

Release Notes

Rich Editor

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.

Heading Formats (Displays 4 possible levels of headings).
List Formats (Numbered List, Bulleted List, Indented & Outdent).
Special Formats (Quote, Code Block, Spoiler).
Standard Format

New Rich Editor formats

Along with the paragraph formatting menu, we've added support for

Additional levels of heading (2, 3, 4, 5). Previously only levels 2 & 3 were available.
Support for nested lists. Lists can now be nested up to 4 levels deep.

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

Images (multiple at a time, including with mixed content).
Lists (Including nested lists).

Rich Quotes enabled by default

Rich Quotes now properly enable by default when enabling the addon. Thanks @R_J.

Image Upload Limits

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.

Keystone Theme

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.

SEO & Performance

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.

Google Sign In

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

Dashboard

Keep left panel of the dashboard pinned to the side when scrolling on long pages.

New or Expanded API endpoints

Set the canonical URL of a discussion

PUT /api/v2/discussions/:id/canonical-url
DELETE /api/v2/discussions/:id/canonical-url

Expand 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/me
GET /api/v2/users/me-counts

These 2 endpoints may be used to fetch information about the currently signed in user.

Record a page view

POST /api/v2/tick

Other Fixes

Discussions/Comments

Fixed an issue where drafts would save even though no text had been inputted or changed. #8722

Categories

Reading all posts in a category will not mark the category as read. #8547

Accessibility

The Pager controls should now be more accessible to users with assistive screen devices (Such as screen readers). #8634

Profile

Profile Extender fields may now be translated. #8566

MichaelTyson · April 2019

Cheers @charrondev! I'll take it for a spin.

R_J · May 2019

I just went through an update from a (clean) Vanilla 2.8 installation and a new Vanilla 3 installation and here is what I found:

Known issues

File access rights: still way to permissive, but that is a known issue on GitHub. Personally I find that this looks unprofessional and untrustworthy and setting this to 755/775 is trivial.

Disabling the Rich editor leaves the forum in an unusable state since users cannot post any more. There already is a GitHub issue for that

Plugins

/dashboard/settings/themes: The "Theming API Test" theme shouldn't be included in a release

The Mark All Viewed plugin has the same effect as marking a category read, doesn't it? I'd say it is not needed any more.

The Google+ Social Connect plugin is still enclosed although deprecated. There's no need to include it in Vanilla 3

UI

There is no space between the comment box and the Post Comment Button when the Rich Editor is not enabled

/settings/gettingstarted: The div.video-section-heading have no space on the left

Rich Editor Errors

Switching between lists eliminates formatted content, here are the steps to reproduce:

1. Write two lines and do some formatting like below

First item - formatted bold

Second item - formatted italic

2. Format that either as bulleted or as numbered list

First item - formatted bold
Second item - formatted italic

3. Switch the list style 😮

First bold
item - formatted

Also using up-/down-arrow key to move lines up or down doesn't work in most cases (at least in Firefox)

prot0n · May 2019

The pictures uploaded trough rich editor does not stay in the original form, they are geting twisted every time, and some mobile devices, even digital cameras are saving their pics in formats like: .PNG, .JPG, dont ask me why, but these formats does not get recognized, only when i change the format of the picture, example, something.PNG into something.png...

charrondev · May 2019

Thanks for your feedback guys. Some of these issues predate the 3.0 release and I won't be back-porting them. It's important to get this release out due to the various bug fixes & some lower priority security fixes that were too risky/not important enough to backport to the 2.8.x branch.

With that said I'm going to try and tackle the following issues before the full 3.0 release.

The disabling rich editor issue. (@R_J I'll get another team member for the second approval tomorrow. Sorry it lingered so long).
Removing the `Theming API Test`.
The image upload bug. I get a sense of dejavu around this one.

Other Notes

The Mark all Viewed plugin is probably a candidate for moving into another repo. That will have to wait until the next release though . It isn't enabled by default and requires some co-ordination for us to move the location of an addon to another repo. It still has a little utility though. (Marks all categories as read instead of just 1 at a time).
The Google+ plugin still actually works (apparently the API isn't totally shut down). We've left it in to give people time to migrate. It will be removed in a future release.
OS permissions are one of those bugs that our operations team has kind of abstracted away from us, but I've bumped the priority and we'll give it a look before 3.1.

charrondev · May 2019

https://open.vanillaforums.com/discussion/comment/256785#Comment_256785

I'm sorry but I was unable to reproduce this. I tested with some .PNG and .JPG images but they worked just fine. I would recommend filing an issue on our issue tracker with some additional reproduction steps (the editor you are using would will also be necessary).

pioc34 · May 2019

Hi all!

I tried to update an existing vanilla 2.8.3 installation with yaga application and i got this error when i made an utility/update :

alter table GDN_Reaction fails.

What i have done:

I copy all files on my local windows installation

I tried an utility/update

I know YAGA is not an official application and official team doesn't support but it's a bug!

I tried an utilit/structure after that and i got this to do :

update `GDN_User` `User`
set `Permissions` = ''
where `Permissions` <> '';

alter table `GDN_Reaction`
-- [Existing: `reactionID` int not null auto_increment, New: `ReactionID` int not null auto_increment]
change `reactionID` `ReactionID` int not null auto_increment,
-- [Existing: `insertUserID` int not null, New: `InsertUserID` int not null]
change `insertUserID` `InsertUserID` int not null,
-- [Existing: `dateInserted` datetime not null, New: `DateInserted` datetime not null]
change `dateInserted` `DateInserted` datetime not null;

alter table `GDN_Reaction`
drop primary key;

alter table `GDN_Reaction`
add primary key (`ReactionID`);

alter table `GDN_Reaction`
drop index IX_Reaction_1;

alter table `GDN_Reaction`
add index IX_Reaction_1 (`InsertUserID`);

alter table `GDN_Comment`
add index IX_Comment_Score (`Score`);

and it failed...

My mysql version 5.7.19

pioc34 · May 2019

I don't see in changelog any core reactions enabling too! I can send to the official team a copy of my database if they want to try by their own.

R_J · May 2019

As you've said: YAGA is not Vanilla, therefore it's not really the right place to solve the problem in this discussion but I'm curious: what do you see if you run /utility/structure in your 2.8.3 concerning the GDN_Reaction table? Do those lines only show up after the update? That would be an interesting finding.

The Reaction table is created by YAGA, therefore you cannot find anything in the logs.

pioc34 · May 2019

Why vanilla try to update GDN_Reaction if it's not a part of the official update. That's the question.

pioc34 · May 2019

i ran utility/update on my 2.8.3 install and no fatal error on GDN_Reaction table...

R_J · May 2019

https://open.vanillaforums.com/discussion/comment/256862#Comment_256862

Addons and plugins have a convention on how to database relevant changes on plugin activation should be bundled. On utility/structure all structure() methods of enabled plugins and all /settings/structure.php files of enabled addons are executed.

https://open.vanillaforums.com/discussion/comment/256864#Comment_256864

I try if I can see that behavior on my installation and if that's the case this should be investigated. This is the code that triggers the error:

// Tracks the data associated with reacting to content
$Construct->Table('Reaction')
       ->PrimaryKey('ReactionID')
       ->Column('InsertUserID', 'int', FALSE, 'index.1')
       ->Column('ActionID', 'int', FALSE, 'index')
       ->Column('ParentID', 'int', TRUE)
       ->Column('ParentType', 'varchar(100)')
       ->Column('ParentAuthorID', 'int', FALSE, 'index')
       ->Column('DateInserted', 'datetime')
       ->Set($Explicit, $Drop);

$result = $SQL->query("SHOW INDEX FROM ${Px}Reaction WHERE Key_name = 'IX_ParentID_ParentType'")->result(); 
if(!$result && !$Construct->CaptureOnly) {
 $SQL->query("ALTER TABLE ${Px}Reaction ADD INDEX IX_ParentID_ParentType (ParentID, ParentType)");
}

pioc34 · May 2019

I think it's a conflict between yaga reaction table and vanilla reaction table.

Look at this file : https://github.com/vanilla/vanilla/blob/release/3.0/applications/dashboard/settings/structure.php#L868

$Construct ->table("reaction") ->primaryKey("reactionID") ->column("reactionOwnerID", "int", false, ["index", "index.record"]) ->column("recordID", "int", false, "index.record") ->column("reactionValue", "int", false) ->column("insertUserID", "int", false, ["index"]) ->column("dateInserted", "datetime") ->set($Explicit, $Drop);

$Construct ->table("reactionOwner") ->primaryKey("reactionOwnerID") ->column("ownerType", "varchar(64)", false, ["index", "unique.record"]) ->column("reactionType", "varchar(64)", false, ["index", "unique.record"]) ->column("recordType", "varchar(64)", false, ["index", "unique.record"]) ->column("insertUserID", "int", false, ["index"]) ->column("dateInserted", "datetime") ->set($Explicit, $Drop);

2 new tables maybe for the next open sources releases of vanilla or cloud part of code...

R_J · May 2019

Just found that, you are right. I didn't experience those problems because my db distinguishes between GDN_reaction and GDN_Reaction.

It might require much effort to solve that problem.

@charrondev there are two tables which belong to the proprietary Reaction plugin which are defined in the dashboards structure:

$Construct
   ->table("reaction")
   ->primaryKey("reactionID")
   ->column("reactionOwnerID", "int", false, ["index", "index.record"])
   ->column("recordID", "int", false, "index.record")
   ->column("reactionValue", "int", false)
   ->column("insertUserID", "int", false, ["index"])
   ->column("dateInserted", "datetime")
   ->set($Explicit, $Drop);

$Construct
   ->table("reactionOwner")
   ->primaryKey("reactionOwnerID")
   ->column("ownerType", "varchar(64)", false, ["index", "unique.record"])
   ->column("reactionType", "varchar(64)", false, ["index", "unique.record"])
   ->column("recordType", "varchar(64)", false, ["index", "unique.record"])
   ->column("insertUserID", "int", false, ["index"])
   ->column("dateInserted", "datetime")
   ->set($Explicit, $Drop);

Normally I'd say they have to be defined in the plugin, but I see that there is a barebone ReactionModel in library/Vanilla/Models. Could you give more information if those tables have been put into the dashboard app by mistake or if they must be there by design?

pioc34 · May 2019

Maybe it could be cool if plugins table names be different from official release tables names. Example :

official release : GDN_reaction

plugin database : Plugin_reaction

I sometime install plugins and if i don't want to use them, i disable them but their tables persists in database...

R_J · May 2019

In this case there is some kind of a workaround: at least on Linux table names are case sensitive. That's why I hadn't those problems. I have GDN_reaction and GDN_Reaction in my test scenario. You can take a look at this part of the MySQL documentation to find out how to change it in your installation.

But at the end of the day it can always happen that table names are duplicate. Even if plugins would have their own naming convention, it would happen all the same if you use similar plugins. For PHP you have namespaces, for a database there is nothing like that.

Maybe I start prefixing tables I create in my plugins from now on or I give them names I define in a class variable so that it would be possible to override them. But I doubt that there is a solution which always fits all cases

pioc34 · May 2019

hum i'm on windows for my tests, maybe this bug is only on windows then....But @charrondev can explain to us what are this reaction and reactionowner tables.

R_J · May 2019

It has been planned here in this GitHub issue, but the other issue referenced which might be able to shed some light on it is in a private repo

Linc · May 2019

Reactions is slowly becoming a core feature. This is step one in that process. Currently it's only being used by an internal app, but we've effectively deprecated building new features on the old closed-source Reactions.