This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Wiki

This wiki is the primary location for developer documentation for Open Y - a digital transformation platform for YMCAs.

Where to Start

For YMCA Associations

For Developers

For QA Engineers


Table of Contents

Community Guidelines

Best Practices

Getting Started with Open Y Development

Whether you are just getting started with Open Y or need to test a feature in a stable environment, the Open Y Core Team maintains a number of Sandboxes that you can use.

Processes & Components

Environment Setup

Contributing to Open Y

Working with Existing Functionality

Adding and Removing Functionality

Dependency Management

Decoupling Open Y

Ongoing Maintenance

Releases

Update Processes & Notices

These documents are for old versions of Open Y, but may contain useful information for troubleshooting future update issues.

1 - Code Review Quality Best Practices

This document serves as an addition to our Code of Conduct and Best Practices. It is more technical and in-depth for specific cases that were discussed during code quality review processes the Open Y team has in place. During this process, all code should be reviewed by 1-2 developers before being merged into the Open Y codebase.

General Rules

Components in Open Y (whether modules, themes, or other code structures) should be, as much as possible, reusable and atomic. All features, content types, settings, styles, etc. should be bundled together to create a cohesive component.

  1. General naming conventions
    1. Features module naming
      1. openy_${entity_type|abbr}_${entity_bundle|abbr}_${feature|optional}
        1. Example: openy_node_blog_feature
        2. openy_prgf_sc_feature -> OpenY Paragraph Simple Content (name within yml)
    2. Fields naming (<=20 chars)
      1. field_${entity_type|abbr}_${entity_bundle|abbr}_{name|abbr}
        1. Example: field_prgf_sc_body
    3. All descriptions are mandatory!
  2. Module naming conventions - Depending on the context we should choose the name from this list:
    1. ${project_name|abbr}_${business_name|abbr} - when the code looks like legacy and has specifics that are not ready to be open-sourced
    2. openy_${business_name|abbr} - when the code is ready to be ejected to OpenY package
    3. ${business_name} - when the code is so abstract that it has no connection to OpenY and is ready to be hosted on Drupal.org as an independent project.

Code Sharing

To support reuse by the community, the MODULE-NAME should relate to the business logic of the module. It is not good to create modules by abstracting them out of the business. All modules that have been shared to drupal.org from past projects were possible to share only because they represent some feature, tied to a business need. For example:

  • personify - module for SOAP related methods for working with Personify API
  • acrypt - Asymmetric crypt algorithm

and so on.

PHP

Return early pattern

To keep readability in functions and methods, it is wise to return early if simple conditions apply that can be checked at the beginning of a method:

<?php

function foo($bar, $baz)
{
    if ($foo) {
        // logic goes here
        return $calculated_value;
    } else {
        return null;
    }
}
?>

It’s better to return early, keeping indentation and brainpower needed to follow the code low.

<?php

function foo($bar, $baz)
{
    if (!$foo) {
        return null;
    }

    // logic goes here
    return $calculated_value;
}
?>

Define early pattern

When you have a condition that aims to change the value of a variable without additional logic, get rid of if else elseif code and instead define your variable early and change it via conditions.

Before:

if ($a = 'hello') {
 $text = 'Welcome to site';
}
else {
 $text = 'Register please';
}

After:

$text = 'Register please';
if ($a = 'hello') {
 $text = 'Welcome to site';
}

Null Checks with isset

isset() verifies if set and not null. There is no need to do additional verification against NULL.

Before:

...
'video' => (isset($feed['profile_media_videos']) || $feed['profile_media_videos'] != NULL) ? $feed['profile_media_videos'] : '',
...

After:

...
'video' => (isset($feed['profile_media_videos'])) ? $feed['profile_media_videos'] : '',
...

Dependency Injection

For the decoupled and easier to upgrade code in Drupal 8+ Dependency injection should be used instead of calling methods from services statically.

See the Drupal API Overview of the Dependency Injection Container and Services.

Before:

...
$node = Drupal::entityTypeManager()->getStorage('node')->load($result->getField('nid')->getValues()[0]);
...

After:

...

$node = $this->entityTypeManager->getStorage('node')->load($result->getField('nid')->getValues()[0]);
...

Creating meaningful log messages

To provide useful logging for site managers, we need to write meaningful log messages with a proper context.

Before:

...
        if($type == 'program') {

          if ($feed['profile_media_videos'] != NULL || $feed['profile_media_images'] != NULL) {
          \Drupal::logger('272')->notice($type);
...

After:

...
        if($type == 'program') {

          if ($feed['profile_media_videos'] != NULL || $feed['profile_media_images'] != NULL) {
          \Drupal::logger('form_import')->notice("FORM IMPORT: type is $type");
...

Maintaining an Upgrade Path

All changes in configurations should be added to appropriate hook_update_N to update already existing environments. We suggest using the Config Importer and Tools package for working with hook_update_N.

Install files

openy.install in profile

In this file, we should put updates that are related to the distribution in general and don’t fit into any feature.

  • Enable/Disable module
  • General configs

openy_*.install in modules

If you update some configuration for a specific feature, make sure that you put updates into this file in the appropriate module.

Config Management

Revert only specific property from config

This is the preferred method of updating configs as it will result in fewer conflicts for upgrading customized Open Y instances.

With config_import module we can update only part of the full config.

For updating specific property in config use the openy_upgrade_tool.param_updater service:

  1. Find the module where your config lives.
  2. Create a new hook_update_N in the openy_*.install file.
  3. In that hook add the update code (for example):
$config = drupal_get_path('module', 'openy_media_image') . '/config/install/views.view.images_library.yml';
$config_importer = \Drupal::service('openy_upgrade_tool.param_updater');
$config_importer->update($config, 'views.view.images_library', 'display.default.display_options.pager');

Where:

  • $config variable contains path to config with config name, like:
  • views.view.images_library - config name
  • display.default.display_options.pager - config specific property (you can set value from a nested array with variable depth)

Revert full configs

This variant uses extensive config file manipulation and increases the time for an upgrade.

For updating full config or several configs from directory use the openy_upgrade_tool.importer service:

$config_dir = drupal_get_path('module', 'openy_media_image') . '/config/install';
$config_importer = \Drupal::service('openy_upgrade_tool.importer');
$config_importer->setDirectory($config_dir);
$config_importer->importConfigs(['views.view.images_library']);

Where:

  • $config_dir - path to directory with config
  • views.view.images_library - config name

Also you can update several configs from a directory:

$config_importer->importConfigs([
  'views.view.images_library',
  'views.view.example_view',
]);

JavaScript includes

image

2 - Composer version constraints for Open Y

In 2020, due to changes in Drupal core release management and demand from Open Y customers to improve upgrade path flexibility and stability, the Open Y team added extended composer version constraints to our composer.json.

Examples from composer.json:

  • "drupal/ckeditor_bootstrap_buttons": "^1.2 || ^2.0.0", - this line means previous version was 1.2 or any 1.x starting from 1.2, and latest tested - 2.0.0 with allowed any stable 2.x starting from 2.0.0
  • "drupal/custom_formatters": "^3.0 || ^3.0@beta", - tested with 3.0 beta of custom_formatters and allowed any 3.x starting from 3.0 (when it will be released)

By having multiple OR (||) conditions we are providing information for developers on which versions could be used for upgrades. There are cases when the latest, even stable version of dependency could be incompatible with some other functionality and it makes sense to keep the version older while functionality is in the process of upgrading.

For example, if, for some reason, custom_formatters 3.0 won’t be compatible with any of Open Y dependencies at the time of release, a developer can select an older beta version in order to proceed with the upgrade.

To select a specific version of a dependency when you do an upgrade of Open Y, add a dependency and its version alongside Open Y at the composer require... step.

For example:

from upgrade doc

composer require ymcatwincities/openy:NEW_VERSION_HERE --no-update
composer update --prefer-dist --with-dependencies --prefer-stable --no-suggest

then change the dependency version

composer require ymcatwincities/openy:NEW_VERSION_HERE --no-update
composer require drupal/custom_formatters:3.0@beta1

You can change any of the dependency versions without upgrading Open Y by running only the composer require... command for specific dependencies and Drupal Update DB routines afterward.

Check official Composer documentation about version constraints and updating Drupal modules with Composer.

3 - Decouple component from Open Y as independent module project

History

In 2019 the Open Y team started decoupling major components to streamline the distribution and simplify support.

Communication started in the Community Board - Ejecting modules from OpenY distro as independent projects.

The decoupling process is ongoing. See the index of decoupled projects.

In 2021 the Open Y core team faced coupling blockers in the distribution during the upgrade from Drupal 8 to Drupal 9

To formalize the ongoing development and maintenance strategy, the Open Y core team shared its decoupling plan with the wider community in mid-2021.

This document elaborates on those processes.

Policy

  • Every new component or sub-project of Open Y should be developed in its own repository - either on GitHub or Drupal.org.
  • The decoupled project could be
  • GitHub should be used when there is no strategy to make a component or project available for the wider Drupal community - that is, when it is tied to YMCA business and unlikely to be leveraged by somebody else.
  • Drupal.org should be used when the component could be useful to projects outside of Open Y.

Process

for creating a new decoupled component

  1. Create a new GitHub/Drupal.org repository.
  2. Work on getting an initial release with at least beta version stability.
  3. Create a composer.json file for the component in order to be able to start using it via composer. See Virtual Y for an example.
  4. Make it available for the public via packagist.org or drupal.org as a release. Ensure podarok is added as a co-maintainer to the respective system.
  5. Suggest adding to Open Y by opening an issue.
  6. If approved, create a Pull Request adding it as a dependency in composer.json.
  7. Ensure this component is enabled in any of the packages maintained in the Open Y profile installation
  8. Ask for review and release, according to the release plan.

for decoupling an existing component of Open Y

Follow the steps above, but:

  • After creating the repo, filter the selected component by running git filter-branch --subdirectory-filter ... from the latest development branch of the Open Y profile. This keeps credits of work done for this component as a part of the Code of Conduct.
  • After separating the code, ensure the ejected code is not duplicated in the Open Y profile. Remove duplicated code in the same Pull Request in which you add the new dependency.

Examples

How to update module on Drupal.org

  • Git filter-branch to get a history of changes.
  • Change git origin to Drupal.org project.
  • Create a new branch and push the code to Drupal.org.
  • Create and push tag to Drupal.org. Create a release on drupal.org.
  • Update composer.json in this distribution with a new tag.

How to decouple module from YN to Drupal.org

Example: paragraph_skins

git clone git@github.com:ymcatwincities/openy.git decouple
rm -rf decouple_copy && cp -a decouple decouple_copy
cd decouple_copy
git filter-branch --subdirectory-filter docroot/modules/contrib/paragraph_skins
git clean -dfx
git remote remove origin && git remote add origin git@git.drupal.org:project/paragraph_skins.git
git pull origin 8.x-1.x --allow-unrelated-histories
# Resolve conflicts if applicable.
git push origin production:8.x-1.x
# Create tags and release on Drupal.org

How to decouple module from Open Y to Open Y Subprojects

Request a repository for the module. Example: shared_content_server

git clone git@github.com:ymcatwincities/openy.git decouple
rm -rf decouple_copy && cp -a decouple decouple_copy
cd decouple_copy
git filter-branch --subdirectory-filter docroot/profiles/contrib/openy/modules/custom/SOME_MODULE_HERE
git clean -dfx
git remote remove origin && git remote add origin git@github.com:Open-Y-subprojects/SOME_MODULE_HERE.git
git push origin production
# Create composer.json on the decoupled repository. Example: https://github.com/ymcatwincities/openy_activity_finder/blob/4.x/composer.json
git clone git@github.com:ynorth-projects/distribution.git yn-distribution
# Update composer json for distrubution. See below

Example for Activity Finder

References

4 - Decoupled (external) projects of OpenY

Inventory of external modules available via Composer

Check all GitHub for the tag openy-decoupled

GitHub hosted

  1. ymcatwincities/openy_block_modal - Implements a simple block with a body and title that will be used to display modal windows.
  2. ymcatwincities/openy_memberships - Membership Framework for OpenY and Drupal.
  3. ymcatwincities/openy_prgf_sidebar_menu - SideBar menu for referencing menu blocks and using in SideBars across different pages.
  4. ymcatwincities/openy_loc_finder - Extended Location Finder
  5. Open-Y-subprojects/reqclique_gxp_sync - Reqclique Group Exercise Sync
  6. open-y-subprojects/virtual_y_signaling_server - Signalling server for Virtual Y
  7. open-y-subprojects/openy_daxko_gxp_syncer - Daxko GroupEx PRO v1 API Syncer into Program Event Framework
  8. open-y-subprojects/ynorth_gxp_spots_proxy - Availability Spots Cache Proxy for Groupex PRO embed API Syncer into PEF
  9. open-y-subprojects/openy_node_alert - Alerts APP for Open Y
  10. open-y-subprojects/openy_focal_point - Open Y Focal Point routines
  11. open-y-subprojects/shared_content_server - Shared Content Server
  12. ynorth-projects/openy_node_session - Open Y Node Session
  13. ynorth-projects/openy_repeat - Repeat API for PEF. Schedules APP built in Vue.js
  14. ynorth-projects/openy_pef_gxp_sync - Groupex Pro Embed/OpenY Syncer into PEF
  15. ymcatwincities/ymca_sync - Syncer backend core
  16. ymcatwincities/openy_activity_finder - Activity Finder app
  17. ymcatwincities/media_entity_document - Media Entity Document
  18. ynorth-projects/openy_prgf_session_table - if you need to present couple of Sessions in a table view without using any complex app like Schedules or Activity Finder

Drupal.org hosted

  1. drupal/upgrade_tool - Open Y Upgrade Tool
  2. ymcatwincities/paragraph_skins - Skins component from OpenY. Decoupled to drupal/paragraph_skins
  3. drupal/openy_autocomplete_path - Open Y Autocomplete Path. Works in Drupal 8 only. Removed from 9.* Open Y releases.

Decoupling mind-map

<code>Open Y decoupling</code>

5 - Dependencies in drupal info.yml

In order to generate composer.json, Drupal.org defines specific rules in the modules info.yml file

If you need to add a dependency to the Drupal.org module you should provide a format:

dependencies:
  - drupal:webform

In this case, your module will have composer dependency to drupal/webform

If you make it:

dependencies:
  - whatevernameyouwish:webform

the Drupal.org packaging routine will replace it with drupal:webform on the fly.

In order to break the dependency on composer level but still tell Drupal core to have module dependency while resolving dependencies during the process of enabling the module, you should use the simplified format:

dependencies:
  - webform

In the above case, composer won’t have any dependencies, but your module will require that the webform module be available in the codebase in order to be enabled by Drupal core.

6 - Deprecate and remove components from Open Y

Occasionally old code is deprecated from the Open Y codebase. In order to minimize disruption to existing sites, we use the following process:

  1. Decide - Before removing components from the distribution we gather feedback from the community to protect active projects from having components accidentally removed. This is accomplished via messaging in the Open Y Slack and discussion on Monthly calls.
  2. Deprecate - Once a decision is made, we notify users that the feature will be removed soon. The deprecated component is moved from the Open Y package group to the Open Y ( Deprecated ) package group. For example: Deprecate Daxko Program Registration Paragraph. Deprecation notices are posted in point and quarterly releases of Open Y.
  3. Uninstall - Before removing code, components should be uninstalled via an update hook in the distribution and any hard dependencies should be removed. Uninstalls must occur at least one point (fix) release after the deprecation notice.
  4. Remove - Complete removal of the component from the codebase or composer.json should happen at least one quarterly (feature) release after the deprecation notice.

Additionally, the following housekeeping steps should be taken when deprecating a component:

  1. The release where the deprecated component has been uninstalled should be added to the important versions document in the Wiki.
  2. Code should be decoupled to external GitHub repositories with all history of commits, marked as openy-decoupled, and archived.

7 - Development FAQ

Open Y Developer FAQ

Local Development

Getting started with a local environment

To start developing you need to obtain the latest Open Y codebase. See the openy-project repository for the full process.

This video tutorial will walk you through how to initiate a local development environment.

The Open Y team has pre-built environments and walkthroughs using either Vagrant and VirtualBox or Docker and Docksal. Choose the method that you’re most comfortable with and get started!

Gathering information about your local environment

To best troubleshoot issues, it’s helpful for the Open Y team to have as much information about your environment as possible. Before you ask for help, watch this tutorial on how to gather that information.

Debugging with Xdebug in your local

The Docksal project maintains detailed information for using Xdebug with VSCode, PHPStorm, and more.

Contributing

Who should I specify for review?

We have a best practice to get at least 2 independent reviews before merging code. Please request a review from the Open Y Lead Technical Architect (Andrii Podanenko, @podarok) and somebody else (from your team or another Open Y partner).

Who is responsible for merging?

The Open Y Lead Technical Architect (Andrii Podanenko, @podarok) is responsible for final approval, merging, and release management on the Open Y project.

What labels in PRs should I use?

What milestone should I specify?

Why I can’t add labels or specify milestones?

All of these require you to be granted Contributor access to the Open Y GitHub repository. Contact the Open Y Lead Technical Architect (Andrii Podanenko, @podarok) to get access. Labels are usually set by the Open Y Core Team.

Why are the steps for review in Pull Requests so important?

When you send your code for review our team must know both how to review the code and what to test to verify the functionality. You are the only source of truth for how to check functionality. Adding steps for review will help the reviewer and QA team to verify that the issue is resolved.

Why should I add a reference to the GitHub issue in my PR description?

As we are a community-led project, there may be a long time between creating an issue and resolving it in a Pull Request. The reviewer should be able to understand the context and possible discussion around the issue to be resolved with your PR. The more context we have, the better and faster we can review the request.

In what format should I add commits, should I add internal Jira task ID or GitHub issue?

It is important to make commit messages with some sort of sense for the human to read them when digging back in history. Adding any task identifications from the project management system is allowed.

What is the “DeepCode” bot?

DeepCode bot is the automated, machine learning code review system that analyses huge amounts of GitHub repositories and is sometimes useful to find common issues before humans do reviews. It is helpful, but not always necessary to fix issues found by the DeepCode bot because sometimes it fails. If you see a comment be sure to read the report. If the report makes sense, then fix the issue suggested by the bot.

Build Automation & CI

What CI processes does Open Y have in place?

To get a fully working Open Y site for the code change you are about to push for review there is a build generating system installed for the Open Y GitHub repository that automatically generates a dedicated temporary website with your changes applied.

Why are some builds created automatically and some not?

By default, builds are configured for trusted users, so if you are getting a message from the bot like

“Can one of the admins verify this patch? Use “o+k to test” or ‘’t+est this please” for manual build execution."

then your username is not in the allowlist and somebody from the Open Y Core Team can comment to initiate a build for you. Contact @podarok to get your build generated or your name added to the allowlist.

How do I create a build for my PR?

If you are on the allowlist then simply create a Pull Request from your fork to the Open Y repository. After up to 30 minutes you’ll receive comments with links to the generated site builds.

When are builds deleted from the server?

Usually, you have a day for the build to be wiped out from the server. If there is an upcoming deadline and many PRs are coming in, the lifetime could be significantly shorter, down to a couple of hours.

Who should I contact to get logs from the build server?

Andrii Podanenko @podarok or Dima Danylevskyi @danylevskyi

What should I do if tests fail?

If you have any concerns with reports generated by the code checkers that are used in Open Y ask Open Y Lead Technical Architect Andrii Podanenko to get them resolved. The majority of these systems are works-in-progress and it is helpful to have feedback on them.

How do I install Open Y on Pantheon hosting

See request from a community. The solution is described in Pantheon’s documentation on nested docroots. We suggest that you maintain your own composer.json with the specified web-root directory, as described in the Pantheon examples.

8 - Drupal 9 core dependencies version flexibility

This document is no longer updated.

To update the version of Drupal being used on your site independent of Open Y see Updating Drupal Core via Composer. Be aware that openy/composer.json may set Drupal core version constraints.


February 2021 release tagged Drupal core both 9.0.x and 9.1.x as allowed to be used.

Composer by default is installing the latest stable version, so a command

composer create-project ymcatwincities/openy-project:dev-9.2.x-development OPENY --no-interaction

will install Open Y on latest 9.1.x Drupal core.

If there is a need to stay on Drupal 9.0.x stable core please use

composer create-project ymcatwincities/openy-project:dev-9.2.x-development OPENY --no-interaction
cd OPENY
composer require drupal/core:~9.0.7

where 9.0.7 - is a needed version for your Open Y instance

For modules see Composer-version-constraints-for-Open-Y

9 - GroupEx PRO quick start

This document has been moved to ynorth-projects/openy_pef_gxp_sync.

10 - How to contribute large features into Open Y (backporting, etc)

Our best practices for backporting large features into Open Y, contributing code for others to use, can be found on this Open Y message board post.

11 - How to develop themes in Open Y

Working with Themes

Each Open Y theme was developed independently, either by the Open Y Core Team or by a partner for one specific Y and then contributed back. You can see demos of each theme on the Sandboxes.

Each theme has its own dependencies and build processes. Please read the steps in each README for details.

Inventory of themes

As of December 2021, themes have been decoupled from the Open Y profile to independent projects on Drupal.org.

Carnation

Lily

Rose

12 - How we release OpenY distribution from code perspective

Repos involved in releases

  1. Open Y Drupal Profile Distribution ymcatwincities/openy
  2. Open Y Project for initiating an Open Y instance - ymcatwincities/openy-project
  3. Continuous Integration/DevOps for rebuilding/installing Open Y - ymcatwincities/openy-cibox-build
  4. CIBox development environment (Virtualbox, Docker, Vagrant) ymcatwincities/openy-cibox-vm
  5. Docksal development environment (Docker, VirtualBox) - ymcatwincities/openy-docksal

Release Management

When tagging a new release of Open Y, the Lead Architect takes the following steps:

  1. Review/Merge/Update ymcatwincities/openy-project (usually composer.json or/and oneline script install) and tag a new release there.
  2. Review/Merge all Pull Requests in ymcatwincities/openy that were planned for release.
  3. Change the Open Y version in openy.info.yml.
  4. Change the Open Y version in major modules if there were changes to them (Activity Finder, PEF, etc).
  5. Create Changelog release notes as a draft and include Contributors as well as major issues fixed/introduced.
  6. Spin up a copy of an Open Y site and check top priority functionality for regressions.
  7. Send for review to Core Team (Craig Paulnock, Paige Kiecker), get approval.
  8. Change the Open Y version to next with -dev suffix for developers in openy.info.yml.
  9. Refresh the Open Y private mirror on the openy.cibox.tools CI server.
  10. Check that the one-click install is working on a fresh DigitalOcean instance ($10: 1CPU 2Gb RAM). Ensure the version of Open Y is the proper one in site info (admin/reports/status).
  11. Publish announcement in #developers Open Y Slack channel.
  12. Publish announcement in #general Open Y Slack channel.

13 - Important versions for upgrade path

Open Y development moves quickly and in this document, we flag important versions that should not be skipped while you upgrade your sites.

Determining your upgrade path

For example: If you are on Open Y 8.1.2 and want to upgrade to Open Y 8.2.8.5 you should make it in a couple of steps

  1. Upgrade 8.1.2 to 8.1.13.1
  2. Upgrade 8.1.13.1 to 8.2.2.1
  3. Upgrade 8.2.2.1 to 8.2.7.3
  4. Upgrade 8.2.7.3 …

These supplemental documents elaborate on a few specific cases:

Important versions

  • 8.1.13.1 - Optional, when you have a lot of customized code and 8.2.2.1 is failing in most places.
  • 8.2.2.1 - This is a very important step everyone should have. After this version, drush entup stops working. In this version, we finally migrated to the core media subsystem, and before going further it is important to upgrade media by upgrading your site to this version first.
  • 8.2.7.3 - This is a very stable Drupal 8 based Open Y with a bunch of contrib module updates. This is one of the last Drupal 8 based Open Y versions before the upgrade to Drupal 9 core. Also, in 8.2.7.0 and 8.2.7.1 we started to introduce multiple version constraints in composer.json to allow developers to choose between the minimum or latest dependency versions. This is for securing the upgrade path as well as adding flexibility for version selection if needed.
  • 9.2.8.0 - Drupal 9 version which must be used in the upgrade path before going to 9.2.8.1+. This version added 9.0-9.1 Drupal Core and disabled deprecated components.
  • 9.2.10.0 - Removed a bunch of unused modules from distribution.

See Version Constraints practices for Open Y

Known issues

If you are faced with an issue when composer installs an improper version of drupal/core for the chosen version of Open Y from the list above, please use this trick in order to downgrade:

composer require drupal/core-recommended:9.2.8

Run the above command where your docroot is. Use the current core version instead of 9.2.8.

14 - Install Solr site search for Open Y

Open Y leverages Apache Solr for a few features:

Quick Start / Upgrade path

  • Log in as admin.
  • Go to admin/modules and enable the Open Y Search API module.

image

  • Approve the next step for enabling Database Search.

image

  • Go to the Search API configuration page admin/config/search/search-api.
  • Verify that the “OpenY Database Search” server is enabled.
  • Visit “Search content” index.

image

tip: Admins can enable and the Solr search and switch the index between servers.

  • Index content by clicking “Index now”.

image

  • Go to the homepage and search for any keyword.

image

  • Verify search results are displayed correctly.

Starting from the Open Y installer

  • Find the Select search service step displayed during the Open Y installation.
  • Choose from one of these options during installation:
    • None
      • Nothing happens if the user chooses this option, search modules are displayed after installation.
    • Open Y Google Custom Search
      • Google Custom Search configuration form is displayed if the user chooses this option.
      • The Open Y Google Search module is enabled after installation and ready to use.
    • Open Y Search API
      • Search API backend options are displayed in this case with the following options:
        • Database
          • The Open Y Search API module is enabled after installation. The database search API server is enabled. The search is ready to use after content indexation.
        • Solr
          • Additional installation step with Solr configuration form is displayed in this case and user can specify all params for Solr connection. The Open Y Search API module is enabled after installation, Solr search API server is enabled. The search is ready to use after content indexing (if the correct Solr settings were used).

Switch from database search backend to Solr backend

Watch a video tutorial on how to switch an existing site from the database backend to a Solr server. This requires a Solr server to be configured in your environment.

  • Edit the “Solr search” server from the Search API configuration admin/config/search/search-api.
  • Add the configuration information for your Solr server. Refer to Drupal’s Search API Solr project for troubleshooting connection information.
  • Save the server and observe that Search API has successfully connected to your server.
  • Edit the “Search content” index and change the “Server” field to the newly configured “Solr Search” index.
  • Visit the “Search content” index and click “Index now” to re-index the content.

Legacy Solr Support

The contrib Search API Solr module supports a broad swath of Solr versions, but occasionally old versions are dropped from support in the main module. If, when enabling Open Y Search API, you encounter errors that your version of Solr is out of date, you may need to enable the [Search API Solr Legacy module]( https://git.drupalcode.org/project/search_api_solr/-/blob/4.x/modules/search_api_solr_legacy/README.md]. As of January 2022, Search API Solr Legacy supports Solr 3.6 through 6.4.

The error message may look something like this:

Notice: Undefined index: 4.x in Drupal\search_api_solr\Controller\SolrConfigSetController->getConfigFiles()

15 - Install SSL certificate for the OpenY site

Web Security and Open Y

As many parties have moved to Encrypt the Web, https sites and SSL certificates have shifted from “nice to have” to necessities.

If you’re running Open Y on a managed platform you most likely have SSL already configured. If you choose to manage Open Y on your own, you’ll have to install a certificate.

Let’s Encrypt is “a free, automated, and open certificate authority (CA), run for the public’s benefit. It is a service provided by the Internet Security Research Group (ISRG).” Certbot is “a free, open source software tool for automatically using Let’s Encrypt certificates on manually-administrated websites to enable HTTPS.”

Certbot maintains detailed documentation for installing SSL certificates on a variety of systems. Simply visit Certbot’s instructions wizard and follow the instructions to configure your server.

16 - Open Y 2.0 root YAML files

There are plenty of YAML configuration files at the root of the profile. Some of them are standard Drupal configuration and others are Open Y specific.

Basic .yml files

The following ones are very common and can be found in many Drupal modules:

  • openy.info.yml ( documentation) - defines Open Y as a profile and defines its name and dependencies
  • openy.libraries.yml ( documentation) - defines global Open Y drupal asset libraries
  • openy.permissions.yml - defines global Open Y permissions
  • openy.services.yml ( documentation) - if you are introducing a service that is needed by all (or the majority of) Open Y modules add it here and store the service class file in the openy/src directory

Open Y specific .yml files

There are also a few configurations related to the Open Y installation process and the Open Y package system:

  • openy.installation_types.yml
  • openy.themes.yml
  • openy.packages.yml

Open Y packages

The Open Y package system introduces a new level of abstraction, shifting from the Drupal standard module level to packages. Packages represent complete Open Y features, which could include multiple modules. A package is a declaration of a group of several modules. You can enable and disable a package, which means the whole set of the associated Drupal modules are enabled or disabled.

This approach provides a convenient way of managing Open Y features.

The Open Y system module provides a page where the enabled and available packages are listed and can be installed/uninstalled. See the Open Y Extend page (at /admin/openy/extend).

Open Y Installation types

When an Open Y site is installed there is also another abstraction level - the installation type - which groups packages.

The hierarchy is as follows:

  • installation type
    • package
      • module
      • module
    • package
      • module
      • module
      • module
    • package
      • module
  • installation type
    • package
      • module

openy.installation_types.yml

openy.installation_types.yml defines the high-level presets available during website installation.

File structure:

standard:
  name: Standard
  packages:
    - alerts
    - editorial
    - news
    - seo
    - webform

extended:
  name: Extended
  packages:
    - alerts
    - analytics
    - ...

complete:
  name: Complete/Developer
  hidden: true
  packages:
    - activenet
    - ...

Each installation type has a machine name which is a key of the top-level items.

Properties of installation types:

  • name (required) - a human-friendly name of the installation type
  • packages (required) - a list of Open Y packages that are associated with the installation type. The packages are listed when a website is installed via the web-interface
  • hidden (optional) - if the installation type must be hidden when a website is installed via the web interface

If an Open Y site is installed using the web interface there is a step where the installation type can be selected.

If an Open Y site is installed using Drush then the installation type can be specified by an optional argument for the drush site-install command ( Installation with Drush):

  drush site-install openy \
     --db-url="mysql://user:pass@host:3306/db" \
     --root=/docroot \
     openy_configure_profile.preset=extended

openy.packages.yml

Packages are defined in openy.packages.yml. This file is placed in the root of the profile, it’s automatically detected and used by the Open Y installation process.

File structure

blog:
  name: 'Blog'
  description: "Blog package provides a set of modules to maintain and create different blog post listings."
  help: '<p>Using Blog package you can create and maintain blog posts and create flexible listings of blog posts. Watch a video below to learn more about blog anatomy.</p>
  <iframe width="560" height="315"
               src="https://www.youtube.com/embed/PTZkgOb8CFE"
               frameborder="0" allow="autoplay; encrypted-media"
               allowfullscreen></iframe>'
  modules:
    - openy_node_blog
    - openy_prgf_blog_listing
    - openy_prgf_featured_blogs
    - openy_prgf_blog_branch
    - openy_prgf_blog_camp
    - openy_prgf_blog_latest
    - openy_txnm_blog_category

camps:
  name: 'Camps'
  description: "Camps package provides a set of modules to maintain camps and add them to the location finder page."
  help: '<p>Using Camps package you can create and maintain Camps and extend location finder page to include them.</p>'
  modules:
    - openy_prgf_camp_menu
    - openy_loc_camp

Each package has a machine name which is a key of the top-level items.

Properties of packages:

  • name (required) - a human-friendly name of the package.
  • description (required) - a short description of the package features to show up on the Open Y Extend page.
  • help (required) - an HTML markup for the installation via web interface. It contains a help message that pops up when the package name is clicked on the Select installation type step.
  • modules (required) - a list of Drupal modules that are associated with the package. When the package is installed/uninstalled the associated modules are installed/uninstalled respectively. When a website is installed via web interface all the available packages are listed there but split into two groups - the ones that are to be installed (associated with the selected package) and all the rest.

openy.theme.yml

The file defines which Open Y themes are available for installation when a website is being installed.

If an Open Y site is installed using Drush then the theme can be specified by an optional argument for the drush site-install command ( Installation with Drush):

  drush site-install openy \
    --db-url="mysql://user:pass@host:3306/db" \
    --root=/docroot \
    openy_configure_profile.preset=extended \
    openy_theme_select.theme=openy_rose

17 - Open Y 3rd-party dependencies

Open Y’s system requirements generally track those of Drupal with some occasional more opinionated recommendations.

General Requirements

Supported versions may differ based on your Drupal version.

Recommended for advanced functionality, but not required:

  • Apache SOLR search server
    • Version 4.9.1 and version 8 have been tested for Activity Finder. Other versions are works in progress.

For high load/performance sites

See also Drupal’s recommendations for managing site performance and scalability.

For development

See our installation instructions for a full walkthrough of these tools.

Software libraries and frameworks

Open Y leverages many other open source frameworks including, but not limited to:

18 - Open Y anti spam protection

In order to protect Open Y customers, we have added anti-spam protection based on CAPTCHA and Google reCAPTCHA out of the box in Open Y core

You can check the tutorial for how to install and configure reCaptcha on your site.

In the majority of cases having the above configuration in place will protect you from 99% of spam, unless there is human-entered spam that has no protection. To overcome some human-based spam you should use blacklist logic for blocking email domains, used in spam messages.

For that, you can use the Protected Submissions module module, which allows you to harden all submissions on a site with a list of stop words as well as per-language settings.

Virtual Y use case

In order to overcome caching issues, Virtual Y uses the simple_recaptcha module which could be used in similar cases.

The CAPTCHA + reCAPTCHA module solution has presented some reliability issues. The most recent discussion and fix from drupal.org has also not reliably resolved issues for some clients.

At some point, the “Simple reCaptcha” module was used on a project and had no issues, so we’ve started to replace the “CAPTCHA” + “reCAPTCHA” modules with “Simple reCAPTCHA”.

19 - Open Y Code of Conduct and Best Practices

The Open Y community aims to build from the methods and best practices of other open-source projects, such as the Drupal community and the Drupal Ukrainian community.

Bylaws

For the OpenY distribution we have Terms of Use and Participant Agreement.

Development

To understand how we use and develop technologies, refer to the documents below:

JavaScript Code Standards

20 - Open Y one-click install how-to

This walk-through is outdated and is in the process of being updated. Instead, try:

Installing Open Y on DigitalOcean droplet

  1. Create Ubuntu 16.04 LTS x64 droplet in area close to your location image

Use 2Gb droplet or more powerful if you need. Do not use 1Gb option - Open Y will fail on it.

  1. Login to the SSH console of the droplet
  2. Follow the comment from https://github.com/ymcatwincities/openy-project/blob/8.1.x/scripts/openyonclickinstall.sh Basically - run a command under root
curl -Ls http://bit.ly/initopeny | bash -s

The command above will run approximately 10 minutes. 4. In the end you should see a message similar to

Open http://127.0.0.1/core/install.php to proceed with OpenY installation.
  1. Open the link from the above message(from your console, not from this document) with your browser and proceed with Open Y installation.

Enjoy.


In order to install the latest beta release of Open Y 2.0 change the command on step 3:

curl -Ls http://bit.ly/initopeny | bash -s beta

If you find any issues please post a message to the issue queue https://github.com/ymcatwincities/openy/issues

21 - Open Y Participant Agreement

OPEN Y PARTICIPATION AGREEMENT

This Open Y Participation Agreement (this “Agreement”) is between Open Y, LLC, and participating YMCA member associations in the United States (“Member Associations”). Open Y, LLC has received license rights from the National Council of Young Men’s Christian Associations of the United States of America, an Illinois not-for-profit corporation (“YUSA”) to provide the Platform (as defined below) to you. Open Y is not a part of YUSA; Open Y is a part of the YMCA of the Greater Twin Cities.

The purpose of the Open Y community is to collectively advance YMCA web and online experiences to better serve the YMCA mission. The terms of this Agreement govern your use of Open Y’s open-source digital content management system, which facilitates the sharing of YUSA brand-compliant website templates, tools, applications, and related digital assets (“Platform”). The community provides a collaborative environment for individuals to positively interact and participate in the Platform. These guidelines address the standards and expectations of those contributing to and participating in the Open Y community and are meant to help our YMCA community grow and thrive. Your participation in Open Y means that you agree to the following guidelines and to the Open Y Terms of Use.

YMCA BRAND ASSETS

No right is granted by this Agreement to use or license the YUSA brand assets. YMCA brand assets, which include, but are not limited to YMCA trademarks, trade dress, logos and other indicia of origin, are owned and controlled by YUSA. Open Y, LLC provides the Platform to you under license from YUSA. Accordingly, neither Open Y, LLC nor any Member Association shall, either directly or indirectly, at any time do any act or thing contesting the validity of YUSA’s trademarks or its rights thereto.

Only Member Associations in the United States will have access to use any YUSA brand assets included in Open Y. All use by Member Associations must be in compliance with YUSA brand standards and guidelines as established by the National Board. YUSA is a third party beneficiary to this Agreement, with the right to enforce each of the terms of this Agreement with respect to Open Y and you. Open Y shall send copies of all notices due to you under this Agreement to each of you and YUSA.

BEING A MEMBER OF OUR COMMUNITY

Participation: Open Y will be at its best if each member participates in the community. There are many different ways you can participate, including through using the platform, presentations, forums, summits, emails, calls, etc. We encourage your active participation to the extent you feel you are able and willing. Open Y, LLC may publicly disclose your participation in the project.

Contribution: Open Y encourages Members to contribute to the enhancement, editing, and building of Open Y. To ensure valuable contributions to the community, Open Y encourages Members to stay familiar and up-to-date with the Open Y roadmap, as well as new features in active development. When you make changes that improve Open Y features, please contribute those back to the community by ensuring they are re-useable and decoupled.

Collaboration: Open Y encourages Members to collaborate across the YMCA community to share costs and efforts on building new capabilities.

Transparency: Customizations of code provided by Open Y for your website will likely increase the initial fees, support, and upgrade costs for your website. When modifying or redistributing code, you must include a notice giving credit to Open Y for the portion of the Open Y code you use.

Promotion: Open Y encourages Members to share their expertise and Open Y experience to expand its reach and accessibility to experienced and new members alike. There will be many opportunities for members to support Open Y and its marketing and messaging initiatives.

Reporting Problems

If you believe someone has violated the Open Y Community Guidelines, or have any questions or concerns, please contact Open Y, LLC at http://openy.org.

22 - Open Y Pull Requests review standard

Check more technical guidelines about our best practices for code quality.

Adherence to Standards

The Open Y Core Team will adhere to the same standards we set for the community for all areas of development and technologies as per the Open Y documentation.

The Open Y Core Team reserves the right to break these standards only in the following scenarios:

  • Emergency - a major defect or security risk has been discovered that requires extreme measures to resolve.
  • When the standards are broken, it is the responsibility of the Open Y Core Team to explain why the standards needed to be broken, and what the new standards will be moving forward.
  • This communication will be posted to the Open Y message board, Slack, and the documentation on GitHub will be updated to reflect the new standards.

Requirements for Pull Requests

  • Code in Pull Requests should follow our established best practices
  • Submitters’ profiles on GitHub or Drupal.org should be up to date and contain at least a name and organization.

Template for the PR

In order to create a good quality Pull Request, we prepared a PR template which is automatically added to new Pull Requests on GitHub.

List of requirements from the template:

  • Provide a link to the original issue, which is going to be fixed by the PR you are creating.
  • All coding styles are fulfilled and there are no issues reported by CodeSniffer. See Code of Conduct.
  • Documentation have been updated according to PR changes.
  • Steps for review have been provided according to PR changes.
    Steps for review
  • Make sure you’ve provided all necessary hook_update_N to support upgrade path.
  • Make sure your git email is associated with an account on drupal.org, otherwise you won’t get commits there.
    drupal.org email
  • If you would like to get credits on drupal.org, check documentation.

23 - Open Y Release Schedule and Guidelines

Open Y Release Guidelines

Open Y releases major releases of the base project Open Y and Virtual Y quarterly. Minor releases and sub-project releases occur as needed.

Major releases (Quarterly)

Major releases are scheduled for the second Tuesday of the second month of each quarter (February, May, August, November). They are numbered 2.x and consist of:

  • New Features
  • New Enhancements
  • New Bugfixes

Minor Releases

Minor releases are numbered 2.x.x and consist of

  • Only bugfixes
  • Never have new features or major enhancements

Release schedule

2021

OpenY/VirtualY Releases for 2021

Prior years

25 - Open Y technology pipeline

To deliver the best technologies for the YMCA movement, the Open Y development community maintains the following documents and best practices:

  1. Development FAQ
  2. Open Y Coding Standards
  3. How new technologies and features are added to Open Y
  4. Sandboxes
  5. Smoke Tests
  6. A Slack Team by invite with an #architects_support channel where we discuss technical issues with our partners and YUSA.
  7. A YouTube playlist for Developers
  8. A list of 3rd party dependencies which are reviewed periodically for new features and deprecations.

26 - Open Y Terms of Use

Version 2.0, May 2018

This is a free service provided by Open Y, LLC (“we,” “us,” and “our”) for users in the YMCA community (“users,” “you,” and “your”). By using the Open Y repository, you agree to these Terms of Use.

We reserve the right to modify or discontinue, temporarily or permanently any services or the Terms of Use at any time, with or without prior notice to users. Open Y, LLC is not liable for any damage to any user or other third party that may result from any such modification, suspension or discontinuance of the service or of the Terms of Use.

Downloading

Open Y, LLC is not responsible for the content maintained in the repository. Any material downloaded or otherwise obtained through your use of our services is done at your own discretion and risk, and you will be solely responsible for any damage to your computer system or loss of data that results from the download of any such material. You agree that we have no responsibility or liability for the deletion of or the failure to store or to transmit, any content or communication maintained by the service. We retain the right to create limits on use and storage at our sole discretion at any time with or without notice.

We are not responsible for the content, data, or actions of third parties, and you release Open Y, LLC, our directors, officers, employees, and agents from any claims and damages, known and unknown, arising out of or in any way connected with any claim you have against any such third parties. No advice or information, whether oral or written, obtained by you from us or through or from our services creates any warranty not expressly stated in these Terms of Use.

All code downloaded from Open Y is based on the Drupal® code base, which is subject to the terms of the Drupal license ( www.drupal.org). Open Y code is a derivative work of Drupal and any distribution must be under the terms of the GNU General Public License version 2 or later versions.

Unless otherwise stated, all content (excluding code), including user-generated content, such as comments and discussions on the Open Y web site, is licensed under Creative Commons License, Attribution-ShareAlike 2.0.

Contributing

The term “contribution” means any source code, object code, patch, tool, sample, graphic, specification, manual, documentation, comments or any other content posted or submitted by you to Open Y. We welcome proposed contributions, however, all contributions are subject to review and approval, and potential modification, before inclusion in a release as part of Open Y.

It is your responsibility to obtain appropriate licensing and attribution for content that you submit to Open Y. Content without appropriate licensing or attribution will be removed.

You represent and warrant that:

  • Each contribution that you submit is an original work of authorship and you can legally grant the rights set out in these Terms of Use;

  • To the best of your knowledge, each contribution will not violate any third party’s copyrights, trademarks, patents, or other intellectual property rights;

  • Each contribution shall be in compliance with U.S. export control laws and other applicable export and import laws.

You agree to notify us if you become aware of any circumstance which would make any of the foregoing representations inaccurate in any respect.

All code must comply with the reasonable standards issued by Open Y, including architecture and security protocols. All code submitted to the repository that is a derivative work must be GPLv2+ compatible and will automatically be redistributed as GPLv2+.

Open Y, LLC in its sole discretion will review, modify and determine whether to include code in its next release. We can refuse or remove any contributions at our discretion and without prior notice.

Disclaimer

All content is provided “as is,” without any warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose and non-infringement; (ii) Open Y, LLC makes no other warranty that its services will meet your requirements, be safe, secure, uninterrupted, timely, accurate, or error-free, or that your information will be secure; and (iii) the entire risk as to the quality and performance of the content is with you.

Limit of Liability

In no event will Open Y, LLC, its affiliates or their licensors, service providers, employees, agents, officers, or directors be liable for any indirect, special, incidental, consequential or punitive damages, including but not limited to loss of revenue, loss of profits, loss of business or anticipated savings, loss of goodwill, and whether caused by tort (including negligence), breach of contract or otherwise, even if foreseeable. The foregoing does not affect any liability which cannot be excluded or limited under applicable law.

Copyright DMCA Notice

If a user or other third party believes that its content has been copied in a way that constitutes copyright infringement, that user or third party should provide Open Y, LLC with the following information: (a) an electronic or physical signature of the person authorized to act on behalf of the owner of the copyright

interest; (b) a description of the copyrighted work that has been infringed; (c) a description of where the allegedly infringing material is located; (d) the affected user or third party’s address, telephone number and email address; (e) a statement by the affected user or third party that he or she has a good faith belief that the disputed use is not authorized by the copyright owner, its agent or the law; and (f) a statement by the affected user or third party, under penalty of perjury, that the above information is accurate and that such user or third party is the copyright owner or is otherwise authorized to act on the copyright owner’s behalf. Please report any alleged copyright infringements to http://openy.org.

Venue and Governing Law This Agreement shall be governed by, and construed in accordance with, the laws of the State of Minnesota, without reference to conflicts of laws principles. The parties agree that the federal and state courts in the county of Hennepin, Minnesota will have exclusive jurisdiction and venue under this Agreement, and each party hereby agrees to submit to such jurisdiction exclusively.

27 - Open Y update sunset - opt out tutorial

Preamble

Back on 28 Jan 2020 Open Y decided to add an anonymous analytics module openy_analytics which was a free opt-in/opt-out solution for the Core team to gather stats from Open Y sites about the frequency of components used.

The idea behind this was to gather data in order to understand the demand for the components in Open Y and use the data to make better decisions.

Recently, the Open Y Core Team decided to sunset this functionality and remove openy_analytics as well as openy_update modules from the Open Y Distribution, as this feature was rarely used. By sunsetting this functionality, we reduced server load from Open Y instances and archive the analytics server.

How to opt-out from analytics subsystem

Visit Open Y -> Terms and Conditions in your Open Y site instance and uncheck the Optional Permissions checkbox

image

After submitting this form your site will stop sending anonymous data.

If the checkbox was not enabled just disregard it, you didn’t opt-in earlier.

Deprecation action

Uninstall and deprecation was done in #2537

28 - OpenY security Drupal-SA-CORE-2018-004

This document is archived but may contain useful information for troubleshooting future updates. For updated update steps, visit How to upgrade Open Y.


To update your OpenY site with security fix from Drupal core https://www.drupal.org/SA-CORE-2018-004 OpenY team is suggesting 2 options- via patch and via Drupal core upgrade(or OpenY upgrade). Drupal core upgrade or OpenY upgrade is not always possible, but security issue should be fixed asap. So consider to apply patch and plan OpenY upgrade later.

How to apply the patch

Patching OpenY releases 8.0.1 - 8.1.10 (Drupal cores 8.2.x, 8.3.x, 8.4.x)

For patching your OpenY release, follow steps below:

  • Login to your production server environment via SSH and find docroot folder of your site codebase. If you installed OpenY by following a tutorial https://www.youtube.com/watch?v=V3K4-RLjxQo - you should: if your site is located in /var/www/html
ssh -l root YOUR_SERVER_DOMAIN_NAME
cd /var/www/html

wget https://raw.githubusercontent.com/ymcatwincities/openy-project/8.1.x/scripts/patches/SA-CORE-2018-004.patch

if your site is located in /var/www/openy

ssh -l root YOUR_SERVER_DOMAIN_NAME
cd /var/www/openy

wget https://raw.githubusercontent.com/ymcatwincities/openy-project/8.1.x/scripts/patches/SA-CORE-2018-004.patch

Now you are ready to patch your site. But before patching - make a backup of the file which is about to be patched

sudo cp docroot/core/lib/Drupal/Core/Security/RequestSanitizer.php /var/backups/RequestSanitizer.php
sudo cp docroot/core/modules/file/src/Element/ManagedFile.php /var/backups/ManagedFile.php

To patch your site run the command to test if the patch can be applied:

patch -p1 --dry-run < SA-CORE-2018-004.patch

You should see a result

# patch -p1 --dry-run < SA-CORE-2018-004.patch
checking file core/lib/Drupal/Core/Security/RequestSanitizer.php
checking file core/modules/file/src/Element/ManagedFile.php

In case if result different - stop on this step and let us know you have issue. In case if all good proceed with a command below, which will patch your site:

patch -p1 < SA-CORE-2018-004.patch

You should see the same output as previously, but now your site is patched.

TIP: In case if you are using git repository for your site run

git add docroot/core/modules/file/src/Element/ManagedFile.php docroot/core/lib/Drupal/Core/Security && git commit -m "Patching OpenY core" && git push

to store your patched core into your own repository.

==========================

How to patch your Digitalocean OpenY install

In case if you have followed tutorial https://www.youtube.com/watch?v=V3K4-RLjxQo you should have your OPenY installed on you DigitalOcean server(droplet) in a predictable for current document folder. That’s why we prepared a short how to patch your OpenY site in a most simple way if you are not a Tech Guru, but just a user

  1. Log in as an admin user to your site admin UI by visiting /user/login URI page.
  2. Login to your DigitalOcean cloud console at digitalocean.com and find Access Console in the dropdown for the droplet you are using for the OpenY image
  3. You should see a popup window with a black screen where console asks you for the login. Use root user and a password generated for you upon droplet creation.
  4. After login to a console run the command below, respectively to the version of your Drupal core.

One line script to patch Drupal core for OpenY

Type manually exact line

bash < <(curl -s https://raw.githubusercontent.com/ymcatwincities/openy-project/8.1.x/scripts/patches/runSA-CORE-2018-004.sh)

and hit Enter. You should see OpenY was patched message.

29 - OpenY security update how to - Update Drupal core only

This document is archived but may contain useful information for troubleshooting future updates. For updated update steps, visit How to upgrade Open Y.


To update your OpenY site with security fix from Drupal core https://www.drupal.org/sa-core-2018-002 OpenY team is suggesting 2 options- via patch and via Drupal core upgrade(or OpenY upgrade). Drupal core upgrade or OpenY upgrade is not always possible, but security issue should be fixed asap. So consider to apply patch and plan OpenY upgrade later.

How to apply patch

Patching OpenY releases 8.0.1 - 8.1.0 (Drupal core 8.2.x)

For patching your very old OpenY release it is highly recommended to upgrade OpenY to latest version or at least to one of the 8.1.1-8.1.6 (Drupal core 8.3.x) with Drupal core upgrade to 8.3.9 https://www.drupal.org/project/drupal/releases/8.3.9 . In case if it is not possible right now, follow steps below:

ssh -l root YOUR_SERVER_DOMAIN_NAME
cd /var/www/html
wget https://raw.githubusercontent.com/ymcatwincities/openy-project/8.1.x/scripts/patches/8.2.x.patch

Now you are ready to patch your site. But before patching - make a backup of the file which is about to be patched

cp docroot/core/lib/Drupal/Core/DrupalKernel.php /var/backups/DrupalKernel.php

To patch your site run the command to test if the patch can be applied:

patch -p1 --dry-run < 8.2.x.patch

You should see a result

# patch -p1 --dry-run < 8.2.x.patch
checking file docroot/core/lib/Drupal/Core/DrupalKernel.php
checking file docroot/core/lib/Drupal/Core/Security/RequestSanitizer.php

In case if result different - stop on this step and let us know you have issue. In case if all good proceed with a command below, which will patch your site:

patch -p1 < 8.2.x.patch

You should see the same output as previously, but now your site is patched.

TIP: In case if you are using git repository for your site run

git add docroot/core/lib/Drupal/Core/DrupalKernel.php docroot/core/lib/Drupal/Core/Security && git commit -m "Patching OpenY core" && git push

to store your patched core into your own repository.

Patching OpenY releases 8.1.1 - 8.1.6 (Drupal core 8.3.x)

For patching your relatively old OpenY release it is highly recommended to upgrade OpenY to latest version or at least to one of the 8.1.7-8.1.10 (Drupal core 8.4.x) with Drupal core upgrade to 8.4.6 https://www.drupal.org/project/drupal/releases/8.4.6 . In case if it is not possible right now, follow steps below:

ssh -l root YOUR_SERVER_DOMAIN_NAME
cd /var/www/html
wget https://raw.githubusercontent.com/ymcatwincities/openy-project/8.1.x/scripts/patches/8.3.x.patch

Now you are ready to patch your site. But before patching - make a backup of the file which is about to be patched

cp docroot/core/lib/Drupal/Core/DrupalKernel.php /var/backups/DrupalKernel.php

To patch your site run the command to test if the patch can be applied:

patch -p1 --dry-run < 8.3.x.patch

You should see a result

# patch -p1 --dry-run < 8.3.x.patch
checking file docroot/core/lib/Drupal/Core/DrupalKernel.php
checking file docroot/core/lib/Drupal/Core/Security/RequestSanitizer.php

In case if result different - stop on this step and let us know you have issue. In case if all good proceed with a command below, which will patch your site:

patch -p1 < 8.3.x.patch

You should see the same output as previously, but now your site is patched.

TIP: In case if you are using git repository for your site run

git add docroot/core/lib/Drupal/Core/DrupalKernel.php docroot/core/lib/Drupal/Core/Security && git commit -m "Patching OpenY core" && git push

to store your patched core into your own repository.

Patching OpenY releases 8.1.7 - 8.1.9 (Drupal core 8.4.x)

For patching your OpenY release it is highly recommended to upgrade OpenY to latest version (8.1.10 or never) or at least to one of the 8.1.10 (Drupal core 8.4.x) with Drupal core upgrade to 8.4.6 https://www.drupal.org/project/drupal/releases/8.4.6 . In case if it is not possible right now, follow steps below:

ssh -l root YOUR_SERVER_DOMAIN_NAME
cd /var/www/html
wget https://raw.githubusercontent.com/ymcatwincities/openy-project/8.1.x/scripts/patches/8.4.x.patch

Now you are ready to patch your site. But before patching - make a backup of the file which is about to be patched

cp docroot/core/lib/Drupal/Core/DrupalKernel.php /var/backups/DrupalKernel.php

To patch your site run the command to test if the patch can be applied:

patch -p1 --dry-run < 8.4.x.patch

You should see a result

# patch -p1 --dry-run < 8.4.x.patch
checking file docroot/core/lib/Drupal/Core/DrupalKernel.php
checking file docroot/core/lib/Drupal/Core/Security/RequestSanitizer.php

In case if result different - stop on this step and let us know you have issue. In case if all good proceed with a command below, which will patch your site:

patch -p1 < 8.4.x.patch

You should see the same output as previously, but now your site is patched.

TIP: In case if you are using git repository for your site run

git add docroot/core/lib/Drupal/Core/DrupalKernel.php docroot/core/lib/Drupal/Core/Security && git commit -m "Patching OpenY core" && git push

to store your patched core into your own repository.

==========================

How to patch your Digitalocean OpenY install

In case if you have followed tutorial https://www.youtube.com/watch?v=V3K4-RLjxQo you should have your OPenY installed on you DigitalOcean server(droplet) in a predictable for current document folder. That’s why we prepared a short how to patch your OpenY site in a most simple way if you are not a Tech Guru, but just a user

  1. Log in as an admin user to your site admin UI by visiting /user/login URI page.
  2. Go to /admin/reports/status after login and search for Drupal Version string. It should be something like 8.2.x, 8.3.x or 8.4.x (x - some number too, like 8.4.2, for example). Based on your finding follow the steps below to your version
  3. Login to your ВigitalOcean cloud console at digitalocean.com and find Access Console in the dropdown for the droplet you are using for the OpenY image
  4. You should see a popup window with a black screen where console asks you for the login. Use root user and a password generated for you upon droplet creation.
  5. After login to a console run the command below, respectively to the version of your Drupal core.

One line script to patch 8.2.x Drupal core for OpenY

Type manually exact line

bash < <(curl -s https://raw.githubusercontent.com/ymcatwincities/openy-project/8.1.x/scripts/patches/run8.2.x.sh)

and hit Enter. You should see OpenY was patched message.

One line script to patch 8.3.x Drupal core for OpenY

Type manually exact line

bash < <(curl -s https://raw.githubusercontent.com/ymcatwincities/openy-project/8.1.x/scripts/patches/run8.3.x.sh)

and hit Enter. You should see OpenY was patched message.

One line script to patch 8.4.x Drupal core for OpenY

Type manually exact line

bash < <(curl -s https://raw.githubusercontent.com/ymcatwincities/openy-project/8.1.x/scripts/patches/run8.2.x.sh)

and hit Enter. You should see OpenY was patched message.

30 - OpenY upgrade for developers - Upgrade to old OpenY 1.x version

This document is archived but may contain useful information for troubleshooting future updates. For updated update steps, visit How to upgrade Open Y.


Upgrade to old, Open Y 1.x version ( tested on upgrading 8.0.2 to 8.1.1.14 )

See upgrade from 8.1.3 to 8.2.2.1

We found the oldest OpenY instance working on 8.0.2 version of OpenY so this document should cover all the way of updating it to the latest version.

Prepare dedicated environment for upgrade testing

Ensure you have working computer or virtual machine with

  • Ubuntu 14.04(16.04 or any decent Ubuntu LTS versions) 64 bit
  • MySQL 5.5+
  • Apache 2.4
  • PHP 5.6-7.1 (7.2 is not supported yet)

OpenY team maintains Vagrant preconfigured Virtualbox based virtual machine with OpenY. Feel free to use it to get working virtual environment. Your own OpenY instance should have Virtual machine injected into your site codebase. Just find Vagrantfile and proceed with vagrant up accordingly to the documentation.

Obtain local copy of your production site

You have to create local copy of your site locally to be able to proceed with the upgrade. For that

  • Make a backup of your production database and copy it to your local machine
  • Make a copy of your production site codebase and copy it to your local machine

  1. Detect version of your OpenY

Starting from OpenY 1.10 release you should see a version of OpenY in your site reports dashboard. For previous versions the best way to check your version is to analyze creation date of index.php pr README.txt file in the docroot folder of your site and compare it to the release date from https://github.com/ymcatwincities/openy/releases . Your OpenY version should be the one which is older than creation date of the files.

  1. Run command with next never version

In a same folder where is your docroot folder run

mv composer.json composer.json.bak || true
wget https://raw.githubusercontent.com/ymcatwincities/openy-project/8.1.x/composer.json
cd docroot/profiles/contrib/openy/
rm -f yparse*
wget https://raw.githubusercontent.com/ymcatwincities/openy-project/8.1.x/scripts/yparse.sh
drush cr
sh yparse.sh | xargs drush en -y
cd ../../../../
composer require ymcatwincities/openy:NEW_VERSION_HERE --no-update
composer update --prefer-dist --with-dependencies --prefer-stable --update-with-all-dependencies --no-suggest
  1. Update the site

Go to docroot folder of your codebase and run

drush updatedb
drush entup

Sometimes, when updatedb fails, it is important to get stable version of some modules we found causing problems

drush dl -y plugin-8.x-2.5 contribute-8.x-1.0-beta7 scheduler-8.x-1.0 views_block_filter_block datalayer simple_menu_icons rabbit_hole metatag simple_sitemap-8.x-2.9 easy_breadcrumb-8.x-1.6
drush en -y plugin contribute scheduler views_block_filter_block datalayer simple_menu_icons rabbit_hole metatag simple_sitemap || true
drush ev "Drupal::service('module_installer')->install(['content_moderation','openy']);"

Ensure commands above finished with no error messages. Best way to check it - run them one more time. If next run shows

$ drush updatedb
No database updates required                                                                                    [success]
$ drush entup
No entity schema updates required                                                                               [success]

You almost 100% proved updated were executed correctly.

  1. Check for regressions

  1. Backup current state of the updated site

  1. Proceed with an update to next version until succeeded (Start from item 1)

31 - OpenY upgrade how to for Developers

Review a video about this document.

Before upgrading, please review these required version steps for your upgrade path.

Overview

Upgrade to Open Y 2.x

Prepare dedicated environment for upgrade testing

Ensure you have a working computer or virtual machine with:

  • Ubuntu 20.04 (16.04, 18.04, or any decent Ubuntu LTS version) 64 bit
  • MySQL 5.7+ (8+ is preferred because of the performance improvements)
  • Apache 2.4 (or Nginx + php-fpm in case if you are fine with htaccess issues down the road)
  • PHP 7.4 (8.0+ could be an issue with some contrib modules)
  • Drush 8.4.10 system version (for Open Y pre 8.2 ). No support for Drush 9.x in Drupal 8 branches. Only in Drupal 9. Use Drush 8.4+ for OpenY 9.2+

The Open Y team maintains Vagrant preconfigured Virtualbox based virtual machine with OpenY. Feel free to use it to get a working virtual environment.

Your own Open Y instance should have a virtual machine injected into your site codebase. Just find Vagrantfile and proceed with vagrant up accordingly to the documentation.

Obtain local copy of your production site

You have to create a local copy of your site locally to be able to proceed with the upgrade.

For that:

  • Make a backup of your production database and copy it to your local machine
  • Make a copy of your production site codebase and copy it to your local machine
  • Ensure you have not manually removed Drupal modules in your database without the uninstallation step being executed! In this case you’ll need to return the module back to the codebase and uninstall it via Drupal Extend UI or Drush before running the next steps to upgrade Open Y.

Run command with next never version ( replace NEW_VERSION_HERE with the version you are upgrading to, e.g 8.2.0.7 )

In the same folder where your docroot is, run:

mv composer.json composer.json.bak || true
wget https://raw.githubusercontent.com/ymcatwincities/openy-project/8.2.x/composer.json
cd docroot/profiles/contrib/openy/
rm -f yparse*
wget https://raw.githubusercontent.com/ymcatwincities/openy-project/8.2.x/scripts/yparse.sh
drush cr
sh yparse.sh | xargs drush en -y
cd ../../../../
composer require ymcatwincities/openy:NEW_VERSION_HERE --no-update
composer update --prefer-dist --with-dependencies --prefer-stable --no-suggest

The script above replaces your composer.json file, so it’s only applicable to websites that have the file unmodified.

If your composer.json file is modified, merge the changes manually. Essentially, the repositories section of the file is updated.

Enable OpenY introduced modules in case if you are updating from very old version or if they are disabled intentionally.

cd docroot
drush en openy_upgrade_tool openy_er openy_prgf_loc_finder openy_map openy_data_wrapper openy_loc_branch openy_focal_point media_directories_ui

Sometimes it is important to get the latest openy_upgrade_tool from the repository even if you are not updating to the latest version of Open Y. You’ll be able to disable them in the end once all updates are executed successfully.

Verify if the Media Entity to Media in Core migration is possible ( only for upgrades from OpenY 1.x to 2.x )

Go to the docroot directory of your codebase and execute:

drush mecu

If the output looks like the following lines, you are good to proceed with database updates.

✓ SUCCESS: All upgrade requirements are met and                      [ok]
you can proceed with the DB updates.
Drupal core is the correct version (>= 8.6.0). [8.6.10 detected]     [ok]
The contributed "Media" module is not installed.                     [ok]
All provider plugins and modules depending on media_entity are       [ok]
up-to-date.
Site uses EXIF handling and the "Media Entity Image EXIF" module is  [ok]
available.

Follow the instructions of the output messages if they contain warnings or errors. Take a look at the detailed guide if you have any troubles.

Update the site

Go to the docroot folder of your codebase and run:

drush updatedb
drush entup

We found, in some instances, because of the complexity of the database you’d need to run this command above up to 6 times to get all entities and updates run to the end. You may ignore errors of the commands until there are no errors after the final run. So:

drush updatedb
drush entup
drush updatedb
drush entup
drush updatedb
drush entup
drush updatedb
drush entup
drush updatedb
drush entup

Please any log errors as issues for the QA team investigate.

If you have issues, the only way to avoid errors is to use Drupal’s hook_update_dependencies API to change the order of running updates to eliminate issues. See this example.

Ensure commands above have finished with no error messages. The best way to check it is to run them one more time. If the next run shows:

$ drush updatedb
No database updates required                                                                                    [success]
$ drush entup
No entity schema updates required                                                                               [success]

You have almost 100% proven updates were executed correctly.

Sometimes, you could face an error like:

openy.terms_and_conditions.schema depends on the Open Y module that will not be installed after import.

In this case, please, ensure that the module connected with this config is enabled.

To make it happen, please execute this command:

drush ev "Drupal::service('module_installer')->install(['module_with_problem']);"

Visit OpenY upgrade tool dashboard

Review and revert or apply an updated version of the configs after the upgrade.

image

Check for regressions

In order to check for regressions during the upgrade, it is best to work with smoke tests. Open Y maintains the smoke tests database document you should use for the process.

Backup current state of the updated site

Use drush sql-dump or another backup tool to take a backup of the site in its current state.

Proceed with an update to next version until succeeded (Start from item 1)

DISCLAIMER: If you have an old 1.x version it makes sense to update to the latest 1.x before going OpenY 2.0 upgrade See OpenY-upgrade-for-developers.-Upgrade-to-old-OpenY-1.x-version

32 - Sandboxes

Open Y Sandboxes for Evaluation and QA

The Open Y core team manages sandboxes for stable and development versions of Open Y to facilitate the evaluation of the product, to help with QA, and enable investigation of issues.

To learn more:

Stable Sandboxes

https://sandboxes.openy.org/

These sandboxes are set to rebuild completely overnight and clear their database and files every 2 hours. To get access visit How can I try or get a demo of Open Y?

These sandboxes contain 3 profile variations:

  • Standard
  • Extended
  • Custom

based on the latest stable release of Open Y.

These sandboxes are built on CI by running:

composer create-project ymcatwincities/openy-project buildnew --no-interaction --prefer-dist

ansible-playbook docroot/reinstall.yml -i /tmp/inventory5068801741271597001.ini -f 5 -e php_env_vars=APP_ENV=dev -e mysql_user=*** -e mysql_password=*** -e mysql_db=sandbox_carnation_custom -e drupal_folder=/var/www/sandbox_carnation_custom -e site_url=https://sandbox-carnation-cus.openy.org -e pp_environment=demo -e run_reinstall=true -e "openy_profile_install_settings='openy_configure_profile.preset=complete openy_theme_select.theme=openy_carnation'" -e use_solr=false -i localhost, --connection=local -vvvv

Development Sandboxes

https://sandboxes-dev.openy.org/

These usually contain the latest development version of Open Y (the master branch of openy.

These sandboxes are built on CI by running:

composer create-project ymcatwincities/openy-project:dev-9.2.x-development buildnew --no-interaction --prefer-dist

ansible-playbook docroot/reinstall.yml -i /tmp/inventory5068801741271597001.ini -f 5 -e php_env_vars=APP_ENV=dev -e mysql_user=*** -e mysql_password=*** -e mysql_db=sandbox_carnation_custom -e drupal_folder=/var/www/sandbox_carnation_custom -e site_url=https://sandbox-carnation-cus.openy.org -e pp_environment=demo -e run_reinstall=true -e "openy_profile_install_settings='openy_configure_profile.preset=complete openy_theme_select.theme=openy_carnation'" -e use_solr=false -i localhost, --connection=local -vvvv

Membership Framework Sandboxes

https://membership-framework-sandboxes-d9.openy.org/

These are based on the Open Y stable Standard profile and the development version of the Membership Framework.

To rebuild the sandbox, CI is running:

composer create-project ymcatwincities/openy-project buildnew --no-interaction --prefer-dist
cd buildnew
composer config minimum-stability dev
composer require "openy/openy_memberships":"dev-master as 1.0.0"
ansible-playbook docroot/reinstall.yml -i /tmp/inventory13097841656330601319.ini -f 5 -e php_env_vars=APP_ENV=dev -e mysql_user=*** -e mysql_password=*** -e mysql_db=d9_sandbox_carnation_std_membership_framework -e drupal_folder=/var/www/d9_sandbox_carnation_std_membership_framework -e site_url=https://sandbox-carnation-std-membership-framework-d9.openy.org -e pp_environment=membership_framework -e run_reinstall=true -e "openy_profile_install_settings='openy_configure_profile.preset=standard openy_theme_select.theme=openy_carnation openy_select_content.content=0'" -e use_solr=false -i localhost, --connection=local -vvvv

Activity Finder Sandboxes - development version

ThemeLinkOpen YProfileActivity FinderThemeBootstrap
Carnationhttps://sandbox-carnation-cus-d9.openy.org/activity-finder-v4stableCustomv4 devv4
Rosehttps://sandbox-rose-cus-d9.openy.org/activity-finder-v4stableCustomv4 devv3
Lilyhttps://sandbox-lily-cus-d9.openy.org/activity-finder-v4stableCustomv4 devv3

To rebuild the sandbox, CI is running:

composer create-project ymcatwincities/openy-project:dev-9.2.x-development-af4 build --no-interaction --prefer-dist
cd ${WORKSPACE}/build
composer require ymcatwincities/openy_activity_finder:"4.x-dev as 4.0"

ansible-playbook docroot/reinstall.yml -i /tmp/inventory4660848605526222353.ini -f 5 -e php_env_vars=APP_ENV=dev -e mysql_user=*** -e mysql_password=*** -e mysql_db=d9_sandbox_carnation_custom -e drupal_folder=/var/www/d9_sandbox_carnation_custom -e site_url=https://sandbox-carnation-cus-d9.openy.org -e pp_environment=demo -e run_reinstall=true -e "openy_profile_install_settings='openy_configure_profile.preset=complete openy_theme_select.theme=openy_carnation'" -i localhost, --connection=local -vvvv

# Solr 4.5-4.9, Activity Finder v4
drush en -y search_api_solr_legacy openy_prgf_activity_finder_4 || true
drush cset -y search_api.server.solr backend_config.connector_config.host 127.0.0.1 -y || true
drush cset -y search_api.server.solr backend_config.connector_config.core ${VHOST_FOLDER} -y
drush cset -y search_api.server.solr backend_config.connector_config.solr_version 4.5 -y
drush search-api-mark-all || true
drush sapi-i || true
drush en -dvy openy_prgf_af4_demo || true

# Solr 4.5-4.9, Activity Finder v4, Carnation theme, bootstrap v4
drush cset -y openy_activity_finder.settings bs_version 4 || true

33 - Secure devops for composer 2 release

This article only applies to long-term users of Open Y. Open Y supports Composer 2 as of version 8.2.7 in November 2020 and new installs use Composer 2 by default.


Composer was upgraded to 2.x on October 30, 2020. This could cause instability when your older composer 1.x accidentally auto-updates to the 2.x version. Issues could include: composer fails to run any commands and blocks OpenY upgrade/maintenance. The instability would be in the developer environment, not Open Y/Drupal.

The Open Y team prepared an avoidance plan for the community to take action steps before the release while Open Y will be verifying Composer 2.x causes no issues or regressions.

If you use Docksal or Vagrant local environments your composer version will not update automatically, so you’re currently safe from inadvertent updates. Instructions for updating those environments will be included with any necessary Open Y updates at a later date.

Case before October 30, 2020, when you are on composer 1.x

Composer 2 is coming and older versions of composer 1.x show the message below.

Composer 2.0 is about to be released and the older 1.x releases will self-update directly to it once it is released. To avoid surprises update now to the latest 1.x version

If you see the message above, ensure your environments have updated composer to the latest 1.x version by running:

composer selfupdate --1

To ensure the above command shows your version 1.x after an upgrade, check the version of composer:

composer --version

You should see something like

MacBook-Pro-Andrii:www podarok$ composer --version
Composer version 1.10.15 2020-10-13 15:59:09

as an output of the command.

If you do not upgrade to the latest 1.x version before October 30, 2020. i.e. if you accidentally upgrade to Composer 2.x

If your composer updated to version 2 and you have issues with this upgrade, the solution is to downgrade Composer to the latest 1.x version by running:

composer selfupdate --1

If you are faced with any issues connect with the Open Y team on GitHub ( create issue) and the #developers channel on Slack.

34 - Testing Open Y for PHP 7.4 version support

Requirements

  • php-cli 7.4 ( memory_limit value should be large ( 2000M ) or unlimiter ( -1 ) in order to not fail
  • composer 2

Steps

  1. Obtain latest development code of Open Y
composer create-project ymcatwincities/openy-project:9.2.x-development-dev openy7.4
  1. Add phpcompatibility to require-dev section
cd open7.4
composer require --dev phpcompatibility/php-compatibility
./vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 7.4 --config-set installed_paths vendor/phpcompatibility/php-compatibility
  1. Generate report
./vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 7.4 --report-file=report.txt

or if you need to skip warnings

./vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 7.4 --report-file=report.txt -n

In report.txt you’d find a full list of findings to be resolved in order to pass compatibility

35 - Upgrade OpenY 8.1.3 to 8.2.2.1

This document is archived but may contain useful information for troubleshooting future updates. For updated update steps, visit How to upgrade Open Y.


Video tutorials

Upgrade OpenY from 8.0.7 to 8.2.2.1 - https://www.youtube.com/watch?v=U_mg0-yKGOI

Document is work in progress

These are instructions for upgrading a very old version of Open Y to the latest version. Given the fact Drupal 8.7+ has no support for automatic entity updates ( BaseFieldDefinitions ) we have to upgrade to 8.2.2.1 of OpenY, which is still on 8.6 Drupal Core, and then update to the latest Open Y version as usual.

Environment

vagrant@vagrant:/var/www/docroot$ uname -a
Linux vagrant 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
vagrant@vagrant:/var/www/docroot$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.1 LTS
Release:	18.04
Codename:	bionic
vagrant@vagrant:/var/www/docroot$ php -v
**PHP 7.1.31-1**+ubuntu18.04.1+deb.sury.org+1 (cli) (built: Aug  7 2019 10:23:12) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.1.31-1+ubuntu18.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.7.2, Copyright (c) 2002-2019, by Derick Rethans
vagrant@vagrant:/var/www/docroot$ drush --version
 **Drush Version   :  8.2.3**
vagrant@vagrant:/var/www/docroot$ composer --version
**Composer version 1.7.2** 2018-08-16 16:57:12

Step by step guide for update

  • Use PHP7.1 for upgrade and install php7.1-mysql php7.1-mcrypt php7.1-cli php7.1-common php7.1-curl php7.1-dev php7.1-fpm php7.1-gd php7.1-mysql php7.1-memcached php7.1-imagic php7.1-xml php7.1-xdebug php7.1-mbstring php7.1-soap php7.1-zip php7.1-xml
  • Go to the folder of OpenY code tree where docroot folder is contained
  • mv composer.json composer.json.orig
  • wget https://raw.githubusercontent.com/ymcatwincities/openy-project/8.2.x/composer.json
  • mkdir -p scripts ; cd scripts && wget https://raw.githubusercontent.com/ymcatwincities/openy-project/8.2.x/scripts/remove_libraries_gitignore_files.sh && cd ..
  • composer require ymcatwincities/openy:8.2.2.1 --no-suggest --no-update
  • composer install --ignore-platform-reqs --no-suggest
  • composer update --prefer-stable --no-suggest
  • cd docroot
  • drush dl -y plugin-8.x-2.5 contribute-8.x-1.0-beta7 scheduler-8.x-1.0 views_block_filter_block datalayer simple_menu_icons rabbit_hole metatag simple_sitemap-8.x-3.0 easy_breadcrumb-8.x-1.6
  • drush en openy_upgrade_tool openy_er openy_prgf_loc_finder openy_map openy_data_wrapper openy_loc_branch content_moderation focal_point
  • drush ev "Drupal::service('module_installer')->install(['openy']);" <- This steps fixes some hidden bug when openy profile removed from core.extension configuration for unknown reason.
  • Manual step (optional, if you have issues with drush updatedb): Edit all yml files in profiles folder to comment media.type.image , field.field.node.program.field_header_content, field.field.node.branch.field_location_amenities in dependencies sections.

image

image

image

  • run drush updatedb -y <- this will fail for the first time ( Media not installed yet ), disregard
  • run drush updatedb -y <- this should run properly.
  • run drush entup

36 - Upgrade use case from 8.2.2.3 to 8.2.7.3

This document is archived but may contain useful information for troubleshooting future updates. For updated update steps, visit How to upgrade Open Y.


1 uninstall lndr and optimizely modules before running composer update commands

2 config to remove


drush cdel image.style.browser_thumbnail

3 enable openy_focal_point and media_directories_ui should be enabled when upgrade from 8.2.2.3 to 8.2.7.3

4 - run drush updatedb and next steps from tutorial