VIDEO
HIGHLIGHT
Log InSign up
2024/03/07 - Weekly Dev Meeting (Backdrop CMS)
SummaryTranscriptChat

2024/03/07 - Weekly Dev Meeting (Backdrop CMS)

Backdrop Weekly Developer Meeting - March 7, 2024

Introductions

  • Nate Lampton introduces himself as the core committer and Technical Lead for the Backdrop project, calling in from Oakland, California.
  • Greg introduces himself from Bon Australia, expressing his passion for contributing to Backdrop despite being a support engineer.
  • Anthony shares his role as a tech lead at Giant Rabbit, supporting nonprofits with Drupal and Backdrop projects.
  • Justin Kristopherson mentions his involvement with infrastructure in Denver, Colorado.
  • Tim Ericson is noted to be away but is also part of the meeting.

Community and Contribution Updates

  • Jen discusses her creation of a discussion node for Backdrop Live in April after summarizing last week's meeting into a blog post on backdropcms.org.
  • She encourages attendees to review the blog post for accuracy and feedback while noting an increase in signups for Backdrop Live following this initiative.

New Contributor Insights

  • A new contributor has ported their first contrib module from Drupal; however, there are questions about maintaining commit history during this process.
  • The discussion revolves around whether all commits from Drupal 7 need to be preserved or if manual changes by current maintainers can suffice instead of original authors receiving credit.

Commit History Concerns

  • There’s concern regarding how much emphasis should be placed on preserving commit history when many Drupal modules have messy histories that could burden new contributors.
  • The group deliberates on whether it’s necessary to maintain complete accuracy in commit history or if practical solutions should take precedence.

Practical Solutions for Porting Modules

  • Suggestions include allowing contributors to redo commits based on patches or file changes while referencing original issues or commits in messages.
  • It is acknowledged that often original commits are not pulled due to branching differences; thus, redoing them with proper attribution may be acceptable.

Discussion on Commit Practices and New Projects

Commit History and Contributor Recognition

  • The speaker discusses the addition of commit history without knowing the original contributor, suggesting that there was no malicious intent behind it. They propose using interactive rebase to credit contributors once their information is known.
  • A recommendation is made to ensure future contributions include proper credit in commit messages, especially when reporting issues related to Drupal modules.

Learning Opportunities for Contributors

  • The conversation highlights a non-blocking learning opportunity for new contributors, emphasizing the importance of recognizing original authors in commits.
  • There’s an acknowledgment of leniency towards new contributors due to the impracticality of maintaining strict commit histories while still attempting to credit original authors where possible.

Community Contributions and Project Updates

  • The discussion shifts towards community contributions, particularly focusing on new projects that were not covered in previous meetings. Several projects are mentioned including "views" and various module enhancements.
  • Specific projects like "save and edit header block dropdown menu," "CK editor inline image styles," and others are noted as part of ongoing development efforts within the community.

Funding Theme Development

  • The speaker references a blog post that ties into questions about potential funding for theme development (both backend/admin themes). They express uncertainty about how this would be structured but emphasize its importance.
  • Questions arise regarding branching for backdrop 2.x, with a suggestion that branching should happen soon. The process involves seeking feedback from project management committee (PMC).

Decision-Making Processes within PMC

  • Clarification is sought on how decisions regarding technical aspects intersect with broader project goals, highlighting the need for PMC input on significant changes.
  • An open issue will be created in PMC discussions to facilitate voting on whether or not to branch for backdrop 2.x, indicating a collaborative approach to decision-making.

Discussion on Opening a 2.0 Branch

Consensus and Communication

  • The speaker suggests that the PMC (Project Management Committee) should state their opinion to ensure everyone is informed, especially those who may not have heard it yet.
  • A discussion in Zulip is proposed to gauge any strong opposition from core committers regarding the opening of a 2.0 branch.

Prerequisites for Branch Creation

  • Emphasis is placed on the need for a public statement outlining what the 2.0 branch means to prevent misunderstandings or conspiracy theories about its implications.
  • It’s suggested to wait until April 5th to create the branch, allowing time for discussions at Backdrop Live and confirming decisions made prior.

Release Process Updates

  • The speaker confirms aiming for consensus before creating the branch and mentions it could serve as an interesting trivia question related to Backdrop Live.

Bug Fix Release Discussion

Current Status of Bug Fixes

  • The topic of today’s meeting revolves around making a first bug fix release for version 1.27, which has been delayed but is now set with issue #6414 opened.
  • There are eight closed issues included in this bug fix release, primarily aimed at smoothing updates from version 1.26.

Upcoming Release Timeline

  • The release process is scheduled to start at 4 PM Pacific Time, with participants encouraged to follow along via issue #6414 and Zulip threads.

Exploration of New Hosting Provider: Aesmo

Transitioning Hosting Providers

  • Jen discusses her experience with Aesmo, noting complications that arose during setup and raising questions about its feasibility for backdropcms.org.

Personal Experiences with Aesmo

  • One participant shares their transition from Pantheon to Aesmo due to moral concerns and increased costs associated with Pantheon hosting services.

Learning Curve and Configuration Insights

  • After spending a day learning how to launch a site on Aesmo, they successfully launched by utilizing best practices tailored specifically for Backdrop sites.

Future Development Plans

  • Plans are discussed about developing a starting platform configuration for Backdrop on Aesmo so future users can benefit from pre-configured settings without extensive setup work.

Backdrop Site Management on Aesmo

Overview of Aesmo's Hosting Plans

  • The speaker is experimenting with Aesmo's lowest plan, a $5/month hobbyist option, to assess its viability for running a backdrop site.
  • Aesmo offers various plans similar to Pantheon, including options for live sites, test sites, and development environments tailored for smaller audiences and simpler configurations.

Managing Backdrop Sites

  • Key components of managing a backdrop site include code, database management (which is user-friendly), and file handling.
  • Unlike Pantheon where configuration files were in the files directory, Aesmo provides a persistent file location that can be customized.

Configuration Challenges

  • Persistent storage complicates version control since it exists separately from the codebase during deployments.
  • The recommended approach involves staging configurations in version control while keeping live directories writable in persistent storage.

Deployment and SSH Access

  • There are challenges with committing live configurations directly from the server due to SSH key limitations; currently requires exporting changes manually.
  • Direct SSH access enhances management capabilities by allowing users to check status and make necessary changes quickly.

Features and Future Considerations

  • The speaker expresses enthusiasm about Aesmo’s features like environment variables for secrets management and support for modern Drupal setups.
  • Plans are underway to discuss experiences using Aesmo at an upcoming event, aiming to gather more insights before fully transitioning backrop cms.org.

How Did We Come to Aesmo?

Introduction to Aesmo

  • The speaker discovered Aesmo during a moral failure at Pantheon, where discussions in the Drupal community led to exploring alternatives.
  • A large Zoom meeting was organized by community members to showcase Aesmo as a new hosting provider, highlighting its version control and multiple site instances management.

Transitioning to Aesmo

  • The speaker has been interested in moving to Aesmo for over a year but received increased interest from customers following recent rate hikes.
  • There are plans to migrate several sites to Aesmo, indicating excitement about the transition.

Viability Concerns

  • The speaker expresses concern about the viability of using Aesmo for backdrop CMS.org, especially if current server maintenance is compromised.
  • An open ticket with the University of Oregon offers potential free managed hosting, which may be preferable due to their established infrastructure.

Comparison of Hosting Options

  • The speaker feels more comfortable seeking free hosting from larger operations like the University of Oregon rather than smaller providers like Aesmo.
  • Despite this preference, there is recognition that if free options become unavailable, Aesmo's lower pricing could still provide an affordable alternative.

Features and Audience Fit

  • The features offered by Aesmo align well with the needs of users transitioning from Pantheon, making it an attractive option for those who find Pantheon's offerings slightly out of reach.
  • Unlike other platforms that base pricing on traffic and views, Aesmo’s model appears more suitable for smaller organizations or projects.

Discussion on Security Issues and Improvements

Security Thread Insights

  • Discussion shifts towards security issues raised in private threads; one issue was found not applicable to backdrop CMS.

Drafting Improvement Issues

  • The speaker mentions drafting issues related to deprecated functions and specific annoyances regarding machine names for permissions that need addressing in future versions (2.x).

Configuration Concerns

  • Another issue involves configuration prefixes causing confusion; suggestions include creating a mapping system similar to existing deprecated function handling.

Preparation for Future Versions

  • Emphasis on preparing deprecations now can help streamline future updates (3.x), ensuring smoother transitions away from outdated configurations.

This structured summary captures key insights and discussions while providing timestamps for easy reference.

Discussion on Permissions and Backward Compatibility

Overview of Current Issues with Permissions

  • The speaker acknowledges limited activity in addressing actual issues but expresses willingness to assist post-meeting, particularly with release sub-desks.
  • An example is given regarding permission names, highlighting the use of spaces in strings (e.g., "access content") which are critical for checking permissions across the system.

Legacy Strings and Future Changes

  • Discussion on maintaining backward compatibility while transitioning to machine names for permissions. The potential removal of legacy string support in future versions is mentioned.
  • A proposal by Greg introduces a deprecated permission function that alerts users about modules using outdated methods, aiming to ease the transition to newer standards.

Handling Deprecated Properties

  • The speaker emphasizes the need for graceful transitions when changing properties on objects, specifically mentioning language handling issues that could lead to errors.
  • Reference made to a recent security commit related to file entities in Drupal 7, leading into discussions about specific issues like allowed extensions.

Configuration Management Challenges

  • Concerns raised about custom code potentially relying on deprecated configurations. A suggestion is made for a deprecation warning system that informs users while still allowing functionality.
  • The process of porting modules from Drupal 7 is discussed, emphasizing naming conventions and how they can complicate configuration management.

Evaluating Risks and Benefits

  • The importance of evaluating risks associated with changes in permissions is highlighted. Potential impacts on the broader ecosystem are considered significant.
  • Acknowledgment that while developer benefits exist, substantial risks may arise from changes affecting all contributions within the backdrop ecosystem.

Configuration Data Types Concerns

  • Frustration expressed over configuration saving practices where boolean values are stored as strings instead of integers. This inconsistency leads to complications during development and implementation.

Discussion on Configuration Consistency in Backdrop CMS

Exploring Configuration Management

  • The current code functions adequately without strict consistency, but there is a desire for improved uniformity in configuration management.
  • A suggestion was made to utilize the default configuration file from a module as a template for data types, allowing automatic checks during config file updates.
  • If changes are made to the default config (e.g., changing zero to false), these should be enforced across all future saves, ensuring consistent data types.
  • A toggle option could be introduced in the hook config info to selectively apply this behavior per file, enhancing flexibility in configuration management.
  • An issue related to this topic has been identified and will be linked for further discussion.

Wrap-Up and Participant Updates

  • The meeting concluded with acknowledgments of participants who were less vocal during the session, emphasizing collaboration and inclusivity.
  • There was a discussion about account access on the events website, highlighting potential barriers for contributors like Anthony regarding participation.
  • Anthony provided an update on his migration journey with Backdrop CMS, noting significant progress on rebuilding themes and addressing client feature requests.
  • He reported being 90% complete with theme reconstruction after overcoming challenges related to nested base themes and panels-based structures.
  • No blocking issues were reported; however, capacity constraints remain a concern for ongoing development efforts.