Best Of

you have to press enter before it turns to a link

No.

You sign up to Google lock in your domain, and results are returned accordingly. I've been doing this for years.

It also serves a purpose that your pages are identified in search engines and that it complies with Google's submission criteria.

I use Google Search instead, set up as a Pocket. Much better.

This is intended. It's the prefix vanilla uses to differentiate between the small & cropped ("n") and large ("p") version of each profile picture.

Figured out - copied code from htaccess.dist file to .htaccess file that was slightly different and that fixed my issue.

I may have resolved the issue when inserting user rows from outside the vanilla world.

To generate the password hash to populate the GDN_User.Password column in a php program, this seems to work:

password_hash($cPassword, PASSWORD_BCRYPT);

where $cPassword is the cleartext password. I also set the GDN_User.HashMethod column to 'Vanilla", but this may not be required.

The newly-added users now get a dialog to enter their password, but this only needs to be done once.

Again, to be clear, we are using sso to handle logins from our intranet, and users cannot sign up except by being approved on our intranet.

I assume you already have run /utility/structure?

There has been a problem with the role table in some updates in Vanilla 2.x

Make sure your role table has a "Type" column and that it is filled (guest, unconfirmed, applicant, member, administrator, moderator). That's how a GDN_Role table looks in a clean install:

SET NAMES utf8;
SET time_zone = '+00:00';
SET foreign_key_checks = 0;
SET sql_mode = 'NO_AUTO_VALUE_ON_ZERO';

SET NAMES utf8mb4;

DROP TABLE IF EXISTS `GDN_Role`;
CREATE TABLE `GDN_Role` (
  `RoleID` int(11) NOT NULL AUTO_INCREMENT,
  `Name` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL,
  `Description` varchar(500) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `Type` enum('guest','unconfirmed','applicant','member','moderator','administrator') COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `Sort` int(11) DEFAULT NULL,
  `Deletable` tinyint(4) NOT NULL DEFAULT '1',
  `CanSession` tinyint(4) NOT NULL DEFAULT '1',
  `PersonalInfo` tinyint(4) NOT NULL DEFAULT '0',
  PRIMARY KEY (`RoleID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

INSERT INTO `GDN_Role` (`RoleID`, `Name`, `Description`, `Type`, `Sort`, `Deletable`, `CanSession`, `PersonalInfo`) VALUES
(2,	'Guest',	'Guests can only view content. Anyone browsing the site who is not signed in is considered to be a \"Guest\".',	'guest',	1,	0,	0,	0),
(3,	'Unconfirmed',	'Users must confirm their emails before becoming full members. They get assigned to this role.',	'unconfirmed',	2,	0,	1,	0),
(4,	'Applicant',	'Users who have applied for membership, but have not yet been accepted. They have the same permissions as guests.',	'applicant',	3,	0,	1,	0),
(8,	'Member',	'Members can participate in discussions.',	'member',	4,	1,	1,	0),
(16,	'Administrator',	'Administrators have permission to do anything.',	'administrator',	6,	1,	1,	0),
(32,	'Moderator',	'Moderators have permission to edit most content.',	'moderator',	5,	1,	1,	0);

If your role table looks different, than this is the problem.

If you change anything in the GDN_Role table, please ensure that GDN_UserRole still contains old values and that this table must be corrected, too!

Quite long ago, there has been an additional problem with some plugins defining new permissions in a wrong way. Check the GDN_Permission table that there is no column with a silly name like "1".