Versions Compared

Old Version 2

changes.mady.by.user Steven Maglio

Saved on

compared with

New Version 3

changes.mady.by.user Steven Maglio

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Topic

Notes

Initial Thoughts

  • Elda - Where the problems that we were facing fixed?

    • Steven - Not to the level that we might have hoped. I fixed the customer facing issues, but alot a lot of the backend / maintenance side that are still problematic.

    • Elda - I think we could move to a composer based system, but I’ll need a list of modules.

    • Elda - I think we would need to using “config split” to turn off Devel in production.

  • Elda - Any custom code is not part of custom modules, I’ll need to know about them.

    • Steven - Let’s add them to the Current State notes below

Scope of Expectations

  • Applying of security and upstream updates

  • There is a hope for an upgrade to Drupal 9

    • Elda - On Drupal 9, all security updates will be handled by Pantheon, and it will be done through Integrated Composer; Pantheon Autopilot

      • Pantheon’s gonna run “integrated composer update”, which should perform the core updates (security and others) by creating a multidev environment and integrating the composer changes from Pantheon’s side and our side, and it will validate the new site runs before reintegrating to Dev. But, it will automatically integrate back to Dev. Elda would verify the site before hand deploying to Test and Live.

  • Elda joining the API Gateway Team

Process Questions

  • How we would handle future small display/functionality updates?

  • How we would handle future larger functionality updates?

Current State (w/ Known Issues)

  • Currently on latest Drupal Core 8.9.19 w/ security updates (not installed through Composer)

    • All modules are updated to the latest, as of

  • There is custom code:

    • Custom Module: ucsb_developer

      • This alters the workflow displays for API Access Request and API Publishing Request to ensure that the State Transitions which appear at the bottom of the “new”, “edit”, and “workflow” tabs all display the correct possible state transitions for the logged in user (based on the users role).

    • Custom alteration to the Apigee Edge module:

      • /modules/contrib/apigee_edge/src/UserDeveloperConverterInterface.php : lines 41~42

      • Code Block
            'firstName' => 'field_first_name', # originally 'first_name'
    'lastName' => 'field_last_name', # orignally 'last_name'

  • Does not use an external SSO login provider (that’s a future project)

    • It does integrate with Apigee’s Developer system (the login credentials are stored in Drupal and they are linked to “Developers” in Apigee)

  • Most modules do not use Composer

    • There are a few modules which are using composer

    • Code Block
      "apigee/apigee-client-php": "^2.0",
"drupal/admin_toolbar": "^3.0",
"drupal/apigee_edge": "^1.20",
"drupal/captcha": "^1.2",
"drupal/markdown": "^1.3",
"drupal/modules_weight": "^1.9",

  • There are two warning messages that appears during dbupdates

    • Module layout_builder has an entry in the system.schema key/value storage, but is not installed.

    • Module workflow_state has an entry in the system.schema key/value storage, but is not installed.

    • I (Steven) believes both of these modules were remove the servers without doing a Uninstall module from the web interface. And these message indicate that the database/configuration has some old values hanging out in it.

    • I (Steven) was able to use these commands on my local installation, but they did not fix the problem when they were run “successfully” on the servers.

      • drush php-eval "\Drupal::keyValue('system.schema')->delete('layout_builder');"

      • drush php-eval "\Drupal::keyValue('system.schema')->delete('workflow_state');"

    • There’s a lot of information in https://ucsb-atlas.atlassian.net/browse/CMPRCWA-139

Process Questions

  • How we would handle future small display/functionality updates?

  • How we would handle future larger functionality updates?

Future Features We Would Like To Pursue

  • The error logs are bloated with errors that can prevent discovering information about real problems.

    • This error message (type) is generated on almost all page requests:

      • A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): entity type: node, bundle: blog, field name: field_keywords

  • The Devel module is turned on in Production; I (Steven) don’t know how to do environment specific configuration in an automated way.

Future Feature Requests

  • Upgrade to Drupal9

    • Elda - I think we may need to make a separate upstream for this site

      • The upstream would contain the patch (which I (Elda) would need to create) for the Apigee Edge module custom code

  • Apigee Teams Feature

    • Would happen along with integrating with Campus SSO

    • This would require custom code to integrate the CAS/Campus SSO registration/login functionality with the Apigee Developer Accounts

Decision to Hand Off

Answering the questions:

  • Does your team have the time for this?

    • The team is just Elda; she would be the one doing this work.

  • Does your team want to take on the responsibility?

Decision

  • We’re going to move forward with the hand-off

  • Elda will be joining the API Gateway Team