🇺🇸United States @sgroundwater

pameeela → credited sgroundwater → .

hestenet → credited sgroundwater → .

I agree/like:

... governance group that would validate and promote 'best in class' recipes

"'verified' (maybe even with a badge in their recipe thumbnail)"

work well and has been tested" would certainly give me a vote of confidence.

Presenting the highest quality in Drupal is critical. A flood of garbage recipes that whitescreen people would be bad.

"verified" (maybe even with a badge in their recipe thumbnail " )

Personally, I like/want this. ^^

duplicate machine names of field names

On some levels this is a best practice situation. Unique prefixes help prevent name collision with fields.

Maybe we start with a Meta page discussing what folks would find valuable as a recipe and create child issues that would be in the individual recipes themselves?

This would be interesting to watch (and learn from.)

For "standards for interoperability" compliance, we could have a published list of best practice "ingredient tags". This would let us filter.

RE:

how to describe what recipes are doing so that users can choose the one that best fits their use case

This is where I'd like to see a schema/vocabulary type file, that holds as much or as little info as needed for a recipe.
For a recipe, we have ingredients, place to purchase them, steps to cook, steps to prepare and serve, kitchen cleanup.

A Recipe Card for Drupal Systems. (.yml)

Removing as unneeded. 

I backed out of these documentation links. The plan is to point people at the most up-to date info in the Document repository.
https://git.drupalcode.org/project/distributions_recipes/-/tree/1.0.x

I backed out of this recent www menu/page until we can confirm the proper plan.
We want to be pointing people to the git repo docs.

moving up a level, pointing people to the git repo. 

Moving this out of Dist amd Recipe doc queue.

Going to remove this from the page, in effort to just push to the git doc repository. 

Hi. I was going to stub in menu links for these two outlines, Maintainer Guide and End User Guide.

I was able to add one link, but was paused adding the second link. I am going to hold up, to give people a chance to review/comment.

This documentation can (should) point to the info in https://git.drupalcode.org/project/distributions_recipes.git.

https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

Last updated on 21 May 2024
This page has not yet been reviewed by Distributions and Recipes initiative maintainer(s) and added to the menu.

https://www.drupal.org/project/distributions_recipes/issues/3381260 →

Working on documentation to help resolve:
https://www.drupal.org/project/distributions_recipes/issues/3381260 →

I added a menu stub pointing to this issue.
(This page can change or be deleted as needed.)

https://www.drupal.org/docs/extending-drupal/contributed-modules/ → contributed-module-documentation/distributions-and-recipes-initiative/recipe-maintainer-documentation →

RE: Starshot and Project Browser can limit the recipes they allow.

For now, recipes that have been registered with Packagist can be installed with composer and should install into /web/recipes/contrib.

Short term, the community Cookbook Page → may organically grow into a directory of available recipes. (This not the one-click solution we are after, but should help people get started for now.)

To prevent duplicated efforts, maybe there could be a recipe-schema.yml type of file, to hold metadata and recipe tags?

Documentation for recipes is being managed in the 1.x project branch. https://git.drupalcode.org/project/distributions_recipes/-/tree/1.0.x

Features and discussions are in the project issues → . https://www.drupal.org/project/issues/distributions_recipes →

A "Recipes Cookbook" page with community information can be found within Drupal.org project documentation → .
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

#!/bin/bash
# commands to pull a local copy of the distributions & recipes documentation. 
git clone https://git.drupalcode.org/project/distributions_recipes.git
cd distributions_recipes
git fetch origin
git checkout -b 1.0.x origin/1.0.x
git branch

This dev branch (currently HEAD detached at commit 03f0b02cb2 on branch 11.x) holds important documentation that was created early on. This spot is hard for people to find.

Should we consider moving this dev documentation out to a separate project, and then incorporate it to compliment the the web-facing wiki page that contains the Community Cookbook?

The root of the documentation in the dev branch is here: https://git.drupalcode.org/project/distributions_recipes/-/tree/03f0b02cb2e87d34dadd07a53eed1fa0f1c5bdad

I like a plan where the current public wiki page for Cookbooks and Related Projects (Link two) can managed as an open resource directory, so maintainers can self identify into the listing. Then incorporate the "Recipe Features Guide" with this wiki page. (Dev branch docs)

Keep the "Recipe Feature Guide" in a repository. Maybe consider converting the MD documentation files into a Gitlabs Page and serve things right from the documentation repo.

Ideas, suggestions?

Reference Doc Link One: →
https://www.drupal.org/docs/extending-drupal/drupal-recipes →

Reference Doc Link Two → :
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

minor text edit for the ECA project link, less is more.

Adding a project package link for ECA.

Progress from the ECA project should get dropped in here. (working.)
Also, I would like to add a FAQ page for working with recipes.  
 

Giving space to implement the composer plugin first is valid. My head just goes to idea that "/recipe" is where I should look for more information.

Modules|Themes|Recipes, these are all different areas. People know to look in /modules and /themes, so it's second nature to want to look in /recipes too.

It's understood that this Readme needs some sections to be TBD for now.
For me, while recipes are in flux, it was helpful to find this development Document:
https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/re...

Here's my updated suggestion. (Yes, it's a readme link to another readme, but the project Readme was the info I needed. )

MORE INFORMATION:
The Distributions and Recipes initiative is evolving rapidly, and so is our documentation. This Readme provides a good starting point, but please note that information will change frequently as the project progresses.
Additional information may be found in the project’s Initiative documentation page.
https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/re...

The Readme needs a few more items, following template format of the Modules and Themes files.

---
Recipes allow the automation of Drupal module install and configuration.

Recipes are supported by new APIs in Drupal 10.3 and 11.0. Recipes are automated site builder steps, in technical terms they are a combination of preconfigured Drupal extensions. Recipes can depend on other recipes, they are composable with other recipes and unlike distributions, do not lock the site in. The eventual goal is that Drupal core itself will offer up recipes instead of install profiles.

DOWNLOAD ADDITIONAL RECIPES
--------------------------
Contributed recipes from the Drupal community may be downloaded at
. (Maybe hold back for now?)

MULTISITE CONFIGURATION
-----------------------
??? We don't want to put in wrong technical info here, so need to confirm if similar text is needed:

In multisite configurations, recipes found in this directory are available to
all sites. You may also put themes in the sites/all/themes directory, and the
versions in sites/all/themes will take precedence over versions of the same
themes that are here. Alternatively, the sites/your_site_name/themes directory
pattern may be used to restrict themes to a specific site instance.

MORE INFORMATION
-----------------
??? Point to the /docs/readme.md, or incorporate it's info here.

... just day dreaming on the UX features:

Can a recipe have: icon, project URL, category tags, etc?
This info would need to be either in the project or in a global registry, maybe both.

My head goes towards being able to add all the project details into the recipe.yml.
(maybe we can already do this?)

Imagine if a site could use Feeds or some other tool to grab a recipe_starshot_index.json or recipe_community_index.json. Then a flexible cookbook page could be built with Views.

Start me off with the Starshot cookbook, but let me run other Recipe Feeds if I want to opt in to community software.

Hear me out on why I say Views, because they're flexible. Just like /admin/content, /admin/recipes would be easy to customize.

Use case, I needed a Department field on my content overview page. Boom, Drupal let me add this easily. Maybe I want to theme a fun card View of my personal recipe cookbook?

Feeds, or some other task, could scan my local /web/recipes/contrib/* and make theses available too.

Feed sources: Global Default (starshot), Global Opt-in (community), Local (contrib)

Wherever we land, I'm sure it will be awesome.
Thanks to the Devs making this happen!

sgroundwater → created an issue.

It should be noted that this project required the HAL module which may have hit end of life for D10.
I'm planning to review this project, to see if it's worth maintaining updates for Drupal 10. It may be possible to achieve similar functionality using the ECA module. (ECA has the potential to serve as a general workflow solution which can replace many single-purpose modules, like this one.)
Depending on how things play out, this module may morph into ECA plugin for Drupal 10.

sgroundwater → made their first commit to this issue’s fork.

sgroundwater → created an issue.

I may have been seeing a similar error when running on PHP 8.x.

Attached is a patch to correct.

Warning: Trying to access array offset on value of type null in field_collection_feeds_presave()
(line 2508 of ... /sites/all/modules/field_collection/field_collection.module).

sgroundwater → created an issue.

I hit the same error w/ PHP 8.x. I let AI help me with a possible fix. In case it helps others.

---
The error message indicates that the property "options" is being modified on a null value in the function flexslider_optionset_load().

To fix this issue, you can add a null check before attempting to modify the "options" property. Here's an updated version of the code that includes the null check:

/**
 * Fetches the given option set and returns it as an object or NULL if no set could be found.
 */
function flexslider_optionset_load($optionset_name) {
  ctools_include('export');
  $optionset = ctools_export_crud_load('flexslider_optionset', $optionset_name);
  
  if ($optionset !== null) {
    // Ensure the optionset is typecast after being loaded from DB
    _flexslider_typecast_optionset($optionset->options);
  }
  
  return $optionset;
}

In the updated code, we added an if statement to check if $optionset is not null before attempting to modify the "options" property. If $optionset is null, the modification will not be executed.

By including this null check, you can prevent the "Attempt to modify property on null" error.

For this error on 7.x-2.x branch:
"Fatal error: Array and string offset access syntax with curly braces is no longer supported in ... /views_php/plugins/views/views_php_handler_field.inc on line 228"

/ * curly brace syntax with square brackets for array access */
foreach ($this->view->style_plugin->rendered_fields[$this->view->row_index] as $field => $value) {
$normalized_row->$field = $value;
}

Also related to PHP updates, in case you see this error:
"Deprecated function: Required parameter $input follows optional parameter $checkbox in include_once() ... "

views_php.module
< function views_php_form_element($handler, $checkbox = FALSE, $input, $variables = array()) {
---
>
> /** See https://git.drupalcode.org/project/views_php/-/commit/3921d99
> *** function views_php_form_element($handler, $checkbox = FALSE, $input, $variables = array()) {
> **/
>
> function views_php_form_element($handler, $checkbox, $input, $variables = array()) {

Greetings All -

I am currently documenting a process for using ECA to run Room Reservation systems on Drupal 9/10. The D7 "Resource Conflict" module was the glue that held my systems together for years. I have a working proof of concept for Resource Conflict Validation using ECA. My solution involves a "Validation View" that ECA consumes when saving or updating Reservations. My plan is to update this documentation while I work on that project. FYI, my target deadline for a workable Reservation system is July 1.

I welcome comments, questions, suggestions or ideas for improvement.
https://snowmaid.com/design/rsvp_system_guide

(My documentation is released under a CC license. Feel free to copy and share as needed.)

jurgenhaas → credited sgroundwater → .

This is not a Core issue, so it is probably safe to close and refer to the Contributed Module issue tracking.

See: Permissions by Term
https://www.drupal.org/project/permissions_by_term/issues/3354478 🐛 Regression updating to 3.1.22 for Drupal 9.x using loadTemplate from twig Fixed

I can confirm, I have the "Permissions by Term" module enabled.
I'm testing the patch for this.

Thanks for the tip-off @cilefen.
https://www.drupal.org/project/permissions_by_term/issues/3354478 🐛 Regression updating to 3.1.22 for Drupal 9.x using loadTemplate from twig Fixed

I'm looking at this issue too. I can duplicate a similar error.

This should be cleaned up and safe to close out as resolved. Thanks all.

I was having trouble locating the project page for info on how to install now that this is removed from core. 
Hopefully it's OK to add a project page link here. 

jurgenhaas → credited sgroundwater → .

Thanks for the feedback! I'll work on these items to move things forward.
- clean up for coding standards
- declared timezone field as required in the config form
- add tests

The workaround in #87 is such a good tip. This is just what I needed.
{{ field_reservation_time__value|date('U') }}
{{ field_reservation_time__end_value|date('U') }}

So a few updates to report. Over in the Tamper module, I just posted an updated patch for a TimeZone Tamper (TimeOffset).
With this patch, a new tamper "TAMPER : TIME_OFFSET" is available. This patch allows you to set a UTC time into any timezone you choose. So you can do things like show a date in two different zones. The patch is failing, probably because of a lack of tests. I'll push on to clean things up.

One additional tip, when working dates, there are three places to be mindful of. System Regional Timezone, a field display's timezone, or a user's local timezone. This took me a bit of time confirming how these settings affect things. (ECA ig grabbing the UTC value from the database.) Dates in the database are stored as UTC without a timezone. For my sites, I'm setting the Regional Timezone as "New York", there is no timezone on my date field, and my local timezone is set to "New York".

https://www.drupal.org/project/tamper/issues/3268276 ✨ Time offset tamper Needs work

I worked out an updated patch that may allow for better functionality, This patch adds a Timezone select list.

RE " but it could be done with date and time tools more efficiently " Yes, I agree.

I just did a quick review test of the patch linked above. While not perfect, it does work. The problem with this patch is that it does not account for DST changes. The date calculation is hard-coded with for a specific number of hours, it does not change based on the time of the year. This patch was really designed for use with Feeds, where the DST offset might not be a showstopper. I am going to take some time to see if I can build on this patch to suite our needs.

@jurgenhass - thanks for the improvement suggestions. (My solution is just a "hack" and is far from optimal or user friendly.)
It looks like there may already be be some work in this direction of your suggestion. I'm reviewing this patch as an option.

https://www.drupal.org/project/tamper/issues/3268276 ✨ Time offset tamper Needs work

While not a direct module port, much of the functionality from this module can now be implemented on Drupal 9/10 using the ECA Module → .
ECA is a workflow module similar to Rules. Currently there is no setup guide for building a conflict workflow in ECA but it is possible to replicate a similar validation process.

As an additional option, Resource Conflict has been ported to the Backdrop CMS.

Functionality proof of concept on D9:

sgroundwater → created an issue.

sgroundwater → created an issue.

jurgenhaas → credited sgroundwater → .

I am also struggling with how to factor for Time Zones.

In the above sample model, the date is a hard coded value. The value does not come from an actual field.

With ECA, when setting a token value from a date field, the value is set as UTC. Outside of ECA, date fields use a view format, which is where you can set a time zone.

I am trying to figure out if I can set a model token, using an existing date field, where the field's display uses my display/timezone format.

It may be possible to create a custom action to help re-calculate a Unix Timestamp based on a static timezone. ( This seems super messy and wrong.)

I feel like I'm missing some easy trick for using date fields.
I welcome any tips.

Big thanks for ECA, it is an incredible tool!