🇮🇪Ireland @marksmith

After updating Charts to version 5.1.1., I also needed to update ChartsDrilldownPluginStyleChart.php of Charts Highcharts Drilldown (version 1.1.0), in line with this PHP error message:

PHP message: PHP Fatal error: Access level to Drupal\\charts_highcharts_drilldown\\Plugin\\views\\style\\ChartsDrilldownPluginStyleChart::getSelectedDataFields() must be protected

Changed:
line 235 in ChartsDrilldownPluginStyleChart.php
from
private function getSelectedDataFields(array $data_providers)
to
protected function getSelectedDataFields(array $data_providers): array
as per this commit suggested above for the 1.0.0-dev version.

marksmith → created an issue.

Unfortunately, the app in question is located on a Plesk interfaced server with limited access to the ssh terminal. I can and did change the php memory size to 512 (which did not help), but have no direct access to the php.ini file or to the root.

marksmith → created an issue.

Also looking for the D10 version of the module. I've found this outdated version off-site: https://github.com/rmelike/commerce_mobilpay Could you, please, create a working variant of this module here? Many thanks.

Also received this error after updating the SimpleOAuth module the new beta6 version via composer (and before running update.php). The site appears to be working normally after running update.php.

marksmith → created an issue.

Unfortunately drupalSettings.path.baseUrl does not work for me on a subdomain like this: https://subdomain1.domain.com (Double clicking gives only the relative path from viewSettings.addForm.) Replacing drupalSettings.path.baseUrl with window.location.origin does work.

Unfortunately, the new 3.0.1 version did not solve the problems above. There remain two lines of code that need to be altered in order to work correctly:

Firstly,
$entity_manager = \Drupal::entityManager();
needs to be changed into:
$entity_manager = \Drupal::service('entity_type.manager');

Secondly, this line:
return \Drupal::messenger()->addMessage($this->t('Items are added to cart successfully.'), 'status');
needs to be changed into:
\Drupal::messenger()->addMessage($this->t('Items are added to cart successfully.'), 'status');

Moreover, I am wondering whether issue https://www.drupal.org/project/views_bulk_operations/issues/3283085 🐛 Error on batch update or delete - Call to a member function isAllowed() on bool Fixed needs to be dealt with within vbo_add_to_cart rather than views_bulk_operations.

I’ve been using this patch successfully on Drupal 10.2. So I think it’s ready for Drupal 10.

This (set of) module(s) comes closest to what I would need for a website administering conferences. That's - I must say - mostly due to the nice drag and drop scheduler functionality which is a particularly user-friendly way of rescheduling sessions/presentations.

However, I'm also looking for a solution that would allow me to manage multiple conferences organized by the same institution over a longer period of time. I'm looking forward to the development proposed in this issue as it would greatly enhance the functionality of this module.

marksmith → created an issue.

This is still a problem with 8.3.Beta3:

  Problem 1
    - drupal/bee[3.0.0-beta1, ..., 3.0.0-beta3] require drupal/bat_booking * -> satisfiable by drupal/bat_booking[1.0.0, 1.1.0, 1.2.0, 1.3.0, 2.1.0].
    - drupal/bat_booking[1.0.0, ..., 1.3.0] require drupal/bat ^1 -> found drupal/bat[1.0.0-rc1, ..., 1.3.0] but it conflicts with your root composer.json require (^10.1@RC).
    - drupal/bat_booking 2.1.0 requires drupal/bat ^2 -> found drupal/bat[2.1.0] but it conflicts with your root composer.json require (^10.1@RC).
    - Root composer.json requires drupal/bee ^3.0@beta -> satisfiable by drupal/bee[3.0.0-beta1, 3.0.0-beta2, 3.0.0-beta3].

Sorry, coming back yet again with the private file issue. The file is correctly saved to the private folder, but it cannot be opened afterwards from the saved content page (Access denied error, even for admin).

Changing issue title in accordance with further discussion.

Private file field works, great job!

Two further errors and suggestions:

1. After saving content (with an entity reference and a file field), datafield throws this error:
TypeError: Unsupported operand types: null + array in Drupal\datafield\Plugin\Field\FieldFormatter\DataFieldTable->viewElements() (line 300 of /var/www/html/web/modules/contrib/datafield/src/Plugin/Field/FieldFormatter/DataFieldTable.php).
This line is problematic: $components[$subfield] += $components['formatter_settings'][$subfield]; does not work. Apparently we need to check whether whether $components[$subfield] is an array before combining it with another array. So this worked:

if (!isset($components[$subfield])) $components[$subfield] = [];
$components[$subfield] += $components['formatter_settings'][$subfield];

This, however, also worked.
$components[$subfield] = $components['formatter_settings'][$subfield];

2. There was another error on saving content:
Warning: Undefined array key "date" in Drupal\datafield\Plugin\Field\FieldFormatter\DataFieldTable->viewElements() (line 297 of modules/contrib/datafield/src/Plugin/Field/FieldFormatter/DataFieldTable.php).

This correction worked:

if (isset($components[$subfield]) && isset($components[$subfield]["type"])) {
  $align[$subfield] = in_array($components[$subfield]["type"], ['integer', 'numeric', 'float']) ? 'right' : '';
}

Much better with RC 5!
A few things I noted.

1. File - It works with the widget option file upload. However, if I select the form widget Media library I receive this error: Warning: Undefined array key "#title" in datafield_preprocess_field_multiple_value_form() (line 196 of /var/www/html/web/modules/contrib/datafield/datafield.module)
2. Have you considered adding an option for private files?

Aside of that:
3. With Devel generate I receive this error: Warning: Undefined array key "date" in Drupal\datafield\Plugin\Field\FieldType\DataField::generateSampleValue() (line 698 of modules/contrib/datafield/src/Plugin/Field/FieldType/DataField.php). (with reference, etc. as well)

Tried with alpha3 (december 31).

I tried with the following data field setup: 1. text field, 2. date field, 3. datetime field, 4. entity reference field.

1. Composer automatically downloads and installs beta2 (even if alpha is requested).
2. Date field is working.
3. Datetime field value gives this error in Reports: Warning: Undefined array key "object" in Drupal\Core\Datetime\Element\Datetime::validateDatetime() (line 365 of /var/www/html/web/core/lib/Drupal/Core/Datetime/Element/Datetime.php)
4. Entity reference field (referencing Article from Basic page) is not working on form view, throws an AJAX error in console and this error in reports: InvalidArgumentException: The #default_value property has to be an entity object or an array of entity objects. in Drupal\Core\Entity\Element\EntityAutocomplete::valueCallback() (line 114 of core/lib/Drupal/Core/Entity/Element/EntityAutocomplete.php).

It's great you started working on this module! I checked the alpha version (dev wasn't working for me). The alpha version basically works with Drupal 10.2, with the limitations that you highlight on the module page (it's not possible to alter the schema after the field had been created).

One thing I observed for now is that I am unable to add more than one value to a multivalue Data field. (One has to edit the content in order to add a further value).

Another thing is that if a date field is added, and the content is edited, it throws this error: InvalidArgumentException: The date cannot be created from a format. in Drupal\Component\Datetime\DateTimePlus::createFromFormat() (line 253 of core/lib/Drupal/Component/Datetime/DateTimePlus.php).

I can confirm this. It appears that several pretty significant changes → were introduced field-wise in Drupal 10.2, which causes much trouble to field-related modules, among others to Custom field.

Thank you for the quick reaction. I understand the problem and I'm eagerly waiting for the fix! Drupal 10.2 introduced a few attractive user friendly updates (an also caused some technical troubles, as I see), so that it would be a pity to miss it. :) Thanks for your efforts invested in this great module!

Thank you for the quick reaction. I can confirm that enhancing the annotation with * category = "reference" (and clearing the cache) solved the problem signalized above.

marksmith → created an issue.

marksmith → created an issue.

I started to test this with the (for me) easier solution, the Field storage config export / import.

Unfortunately this solution does not working for me, as it leads to the unable to alter the schema error: "Unexpected error during import with operation update for field.storage.node.field_name: The SQL storage cannot change the schema for an existing field (field_name in node entity) with data."

I suppose that the scenario I am looking for - that one would want to alter the datafield schema already containing data at some future moment - is quite realistic, and it would be ideal to have a UI solution for this. I understand that this would require a good amount of work on this module though. So, thank you for the effort invested thus far.

Thanks for the quick reply! Is there a description how adding a new column to a datafield (already containing data) actually works? As far as I see, this cannot be achieved via the regular UI ("cannot be changed once data has been created").

marksmith → created an issue.

Okay, just for the record, in case others arrive at this page with similar questions related to the two modules.

I checked the entity reference problem you discuss above on DataField with the following setup (that you recommended on the page linked in your comment above):
1. I set content entity A(rticle) to reference content entity B(asic page) and entity B reference entity A.
2. The references are working as expected if on the manage display setting the formatter type is selected as "Label" on both entity types.
3. This setup does not appear to work if the formatter type of the entity reference field is changed to "Rendered entity" on one or both content types. (Both modules are new to me and I am not competent enough to say whether this is related to the recursive rendering issue discussed above [no error log messages]. At any rate, if I reset the formatter type to "Label" on one of the entities [!], the content displays are working again [one rendering the label, and the other one rendering the entity]).

Thanks again!

Thanks for the prompt and detailed reply! After a closer look at how the two modules work, I do indeed appreciate the attention Custom Field gives to testing, detailed documentation, and also the probable use case where an existing data structure needs to be extended at some point. I do find, however, that implementing some support for entity reference would greatly enhance the usability of this module. Doesn't Drupal's built in recursive rendering protection provide sufficient assurance for what you are fearing of?

marksmith → created an issue.

marksmith → created an issue.

On a closer look, this has nothing to do with Stripe (although it appeared on my site after I deleted and recreated a Stripe payment gateway). It duplicates tickets with any (including Manual) payment method.

Coming back to this issue upon an update of the Stripe payment method, which also affects Commerce Ticketing. I'm not sure where the problem may be. Sorry if choosing the wrong forum.

Having Commerce Stripe 8.x-1.0 as the payment gateway, the commerce tickets were created as expected, but failed to be activated on order completion (even if this was the expected behaviour set on the product variation page, the ticket state remained: Created).

After updating to the recent Commerce Stripe 8.x-1.1 the tickets are indeed activated (!) on order completion, but each ticket is created (and activated) twice.

marksmith → created an issue.

Ok, now I see it. The problem is with this line of code:

      ->setDisplayOptions('form', [
        'type' => 'integer',
        'weight' => 10,
      ])

which should be:

      ->setDisplayOptions('form', [
        'widget_type' => 'integer',
        'weight' => 10,
      ])

This code change solves the problem in my case.

marksmith → created an issue.

marksmith → created an issue.

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

marksmith → created an issue.

Your initial question was about the creating a new entity event. You mention an update event in your last question, which is a different event. I don't know where the error might come from, perhaps the relation between the two events is not properly configured. Did you configure the two events within the same model? I didn't notice any error messages with my configuration attached below.

marksmith → created an issue.

1. First install and enable the ECA Tamper (and Tamper) modules.
2. Create the fields, like: field_integer_1, field_integer_2, field_result
3. Set up the ECA as follows.

3.1. Add event: choose the Insert content entity event type, select entity type and bundle where the fields are located

3.2. Add the Tamper:Math task to the event, with the following configuration:
Data: [entity:field_integer_1:value]
Token name: result (no square brackets!) / you are free to choose your token name (see under 3.3)
Operation: Addition
Value: [entity:field_integer_2:value]

3.3. Add the Entity:Set field value task to the previous task with the following configuration:
Method: set and clear previous value
Field name: field_result (no square brackets here!)
Save entity: Yes
Field value: [result] (use the square brackets, refers to the token name assigned under 3.2.)

You can achieve that with the ECA Tamper module.

Thank you for bearing with me. Not quite there yet. I describe a simple use case.:

1. Entity has a numeric field, say field_date.
2. Via ECA I would like to interact with that field as a user during the execution process. One example: rewrite the value of field_date by adding to it a value that I will provide. Say add +30 days to all dates that I selected (via ECA VBO, and ECA Tamper).

The point is that the value which should be added to the existing field_date field value is provided on the fly, during the execution, for instance through a modal dialog form. (There is such an option to interact within the Flag module (Form behavior - Modal dialog)).

Thanks again. I have further tailored the script, here's what I found.

Load entity action is, indeed, not necessary. However:

1. If I choose the "Display a message to the user" action to display the value of the field_date field, the right token to be inserted in the Message section is [entity:field_date:value], as you suggested.
2. If I choose the "Get field value" action (or Set field value, for that matter), the token above did not work. I needed to insert only field_date in the Field name (without the brackets).
3. The ECA tamper (used for the Convert date to timestamp action) also uses the tokenized variant in its Data field[entity:field_date:value].

A bit confusing to follow when tokens should be used and when not, but it works, nonetheless.

Thank you for these excellent modules!

marksmith → created an issue.

This module appears to interfere (conflict) with the BAT module → (Booking and Availability Management Tools for Drupal).

Both create a *booking* table in the database upon install, which is removed on uninstall with all the consequences.

marksmith → created an issue.

Thank you for the quick tip! It's a working solution. A quick repro of how it works (for others, like me, searching):

1. Add VBO Execute views bulk op (one-by-one) event and the VBO access event (as per readme.md)
2. Load entity action: Load entity from type and ID (in my case commerce Product, ID is: [event:entity:id]) - assigned token name: product_entity
3. Entity Get field value action - field name: field_date - assigned token name: current_date_value - Entity: [product_entity] (as established above)
4. Field value is now available and I was able to tamper it according to my needs.

Thanks's again for the excellent support!

marksmith → created an issue.

marksmith → created an issue.

marksmith → created an issue.

marksmith → created an issue.

Do you have a rewrite in the field to be summed by VAP? For me the SUM column aggregation function works as expected with regular decimal field with suffix. It does not work, however, if this operation is performed on a twig rewritten custom field, with math calculation that also contains non-numeric values. See both instances in the attached screenshot (D 9.5.3).