🇭🇺Hungary @Balu Ertl

baluertl → created an issue.

In light of Lenny's recent updates 📌 [META] Track 3: Drupal Starshot documentation Active , it seems there’s no need to shift the target audience of this User Guide project to focus on the Drupal CMS product. A dedicated documentation effort is already being handled by the excellent team at Drupalize.me. As such, I’m withdrawing the point I raised in #8 📌 Decide on the future of the user guide Active , as it’s now clear this isn’t a concern.

That said, I’m left wondering whether Drupal Core (which is primarily aimed at developers, unlike Drupal CMS) truly needs a hands-on guide at all.

Glad to hear others also like the idea. From what I gather about the Starshot project through its communications, its aim seems to focus on serving an audience that Drupal Core alone has struggled to engage: non-coder site builders who prefer working exclusively through a graphical user interface. While I can’t speak on behalf of the original authors of the User Guide (Jennifer, Amber, Joe, and many others whose contributions deserve to be honored, though I regretfully can’t recall all their names), my experience working on the Hungarian translation left me with the impression that it was written with a very similar audience in mind.

As Drupal 8 was era-shifting in its terms, I believe, Drupal CMS is also expected to be so too. Publishing the 1. edition of the User Guide at the time of such a groundbreaking change was an extremely valuable aid to assist many over the gap. I think Drupal CMS's initial adoption could be further supported if we dedicate the 2nd edition of the User Guide solely to them.

Oppositely, I don't really see the point in mixing Drupal Core × Drupal CMS in the same book. It just makes no sense at all to me, because those are two very distinctive products sold to different audiences.

All valuable points absolutely worth finding some freetime to read through all your arguments. However, until then just briefly dropping here a question: is this thread the good place to think about whether we want to consider updating “The Next Big Edition” of the user guide for Drupal CMS instead? Or maybe I have missed the point when it has been already decided that the User Guide must be about Core?

These 2 sentences: “Everything in this file is optional” and “The props section is currently required” seems logically conflicting for me, aren't they?

Minor markup organizing and stylistic improvements.

• Remove mentioning “experimental” as SDC is in Core now.
• Referencing PHP classes more precisely wherever applicable.
• Replace spaces in machine name as it's disallowed.

Only stylistic improvements, no content changes.

Demote version-related note to the bottom of the page as it's being displayed on almost every page of this guide.

Demote version-related note to the bottom of the page as it's being displayed on almost every page of this guide.

Demote version-related note to the bottom of the page as it's being displayed on almost every page of this guide.

Demote version-related note to the bottom of the page as it's being displayed on almost every page of this guide.

Still trying to avoid callout title being picked up as section title.

Demote version-related note to the bottom of the page as it's being displayed on almost every page of this guide.

Trying to avoid version note to be picked up as section title.

Update & simplify the callout to the actual Core version.

Update & simplify the callout to the actual Core version.

baluertl → created an issue.

Here we go: 8.x-1.4 → .

Thanks for everyone for their patience, here we go: 8.x-1.4 →

It’s worth noting a small UI improvement: following the convention of similar contrib projects (eg. config_export_ignore, config_export_json, config_devel, config_ignore, config_split, etc.), I’ve updated the package name on the Extend page from the rather generic “Development” to the more descriptive “Config” group:

Thanks for everyone for their patience, here we go: 8.x-1.4 →

It’s worth noting a small UI improvement: following the convention of similar contrib projects, I’ve updated the package name on the Extend page from the rather generic “Development” to the more descriptive “Config” group:

baluertl → created an issue.

The initial question in the issue title has been answered in Comment #4 ✨ searching assets based on file format Active , therefore I think we can close this one.

As discussed with @japerry → recently, all these changes goes onto the MR of 🌱 Roadmap to the next release of the `acquia_dam` module Active for the sake of simpler overview.

baluertl → changed the visibility of the branch stable-release-related-fixes to active.

baluertl → created an issue.

Also linking ✨ Dynamic filter for collections Active here as well for visibility.

It was probably a momentary lapse in judgment that led me to think, 'Not all Drupal users are Widen users too.' Of course, they must have a registered user account; otherwise, they wouldn’t be able to authenticate themselves on the Drupal side either. As a result, I’ve downgraded the significance of this potential disadvantage to being a minor UX flaw instead."

Adding a possible disadvantage.

baluertl → created an issue.

baluertl → changed the visibility of the branch stable-release-related-fixes to hidden.

While working other things I just stumbled upon the same on the latest 1.1.x-dev version as well:

Memo: whoever will work on this, please make sure that all other non-URL-friendly characters are also tested for, not only the forward slash. Thanks!

On Acquia's internal channels, we have received reports of very similar errors to happen. Based on the formatting of error messages I see on Watchdog screenshots, I can tell that the Customer was using a version of this module before the MR !84 was merged.

Although handling of HTTP 4xx errors from asset-related API requests has been improved in the 1.1.x branch, but it is uncertain whether it covers integration link-related requests too or not. Independently from HTTP 4xx errors, I do agree with @capysara → 's suspicion about if the CRUD operations of integration links are not in full sync with the DAM assets during their entire lifecycle. As the auto-hiding logic instantly sets media items unpublished at any time when the Widen API returns a response with negative meaning (aka. asset unavailable or deleted), these are not permanent changes on Widen's side (asset can be available later on and even can be restored from trashbin by admin). Therefore we don't delete media items automatically, so – up to my current understanding – we should not delete integration links either.

For the sake of transparency (and because we have referenced this ticket earlier from various sources) I restored its original issue description which was clearly about solving the link deletion problems. Also, bumping branch up to 1.1.x because it could be easier due to the aforementioned feature already implemented there.

At the moment I have no access to any Widen instance hosted on *.acquiadam.com sub-domain (only those that run from the old *.widencollective.com), therefore I would kindly ask anyone who has access to test our proposed bugfix on MR !97.

The expected behavior is: when browsing the media library modal window, all (except Audio & Generic – another issue 📌 Generalize embed codes of audio and generic asset types Active ) kind of DAM assets should properly display a thumbnail image. The same applies to the Views list on the /admin/content/dam-media page too. Right-click on any thumbnail image, checking its URI in most (all?) cases should point to a CDN-related hostname.

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

The solution provided here has been merged into both development branches, therefore I think we can close this ticket as Fixed.

Thanks @paladyn → for reporting this. I just got informed about this 'acquiadam.com' domain name recently from Widen's docs → . Although I cannot promise for sure, but I do agree that it would be extremely helpful if we could roll out the upcoming 1.1.0 stable release with properly prepared to handle this new domain name pattern too.

baluertl → changed the visibility of the branch 3478118-rc1-release-related-fixes to hidden.

1. Port changes from MR !51 to branch 1.1.x as MR !95
2. Remove the unnecessary Form title override, use the Page title from the routing itself instead
3. Delete the unnecessary fieldset form element
4. Replace instructions with a much more informative description about the purpose of this page
5. Invoke the parent form logic to allow alteration by anyone else
6. Use the action button inherited from the parent form controller
7. Do not render the form if there is no metadata from the Widen API

Current implementation:

baluertl → changed the visibility of the branch 3444915-allow-enabling-all to hidden.

baluertl → changed the visibility of the branch 1.1.x to hidden.

In general terms, I like the idea, thanks for bringing it up and creating an MR. Some objectives from me:

• The naming of the new option should fit into the semantical pattern of already existing ones, which mostly (all?) describe what the editor will receive when choosing that option (eg. “inline_view”, “link_thumbnail_download”, and “link_thumbnail”). Oppositely, the suggested name “background_video” represents a possible purpose for how this option can be used.
  
  After some testing, I found the proposed setup very similar to the already existing “video_stream” option. Therefore I suggest we could help the content editors understand better the difference between these two.
• The autoplay feature activates within the WYSIWYG editor as well. I did not started to investigate any possibilities to its specific disablement, so we can handle it as a known issue until hearing back end-user complaints.

The current implementation:

We are still keeping this ticket open until the final goal (1.1.0 stable got released) is achieved.

Resolved in 1.1.x-dev branch:

Disclaimer: I am not a member of the Product Team that makes decisions about the direction of forthcoming development but I can hardly imagine such a data communication would be implemented in the near future. The entire ecosystem is built upon the concept that Widen is the central SSoT and one or more client websites connect it to fetch data from. Allowing backward would require a major overhaul of the entire current architecture. Sorry, this is a strong -1 from me.

baluertl → changed the visibility of the branch 1.0.x to hidden.

baluertl → changed the visibility of the branch 3443055-handle-unavailable-widen-assets-11x to hidden.

baluertl → created an issue.

After the merge request has been merged, I cannot see any major difference between how the dropdown list works for an embedded image (not counting the last option with ling name which was added in a separate MR):

@jura.khrapunov → / @ok4p1 → / @vadim.hirbu → could any of you please update the issue description with a proper list of steps for reproduction? Otherwise, it's hard to tell the issue status until it's unclear what the exact expectations were. Thanks in advance!

After the merge request has been merged, I cannot see any major difference between how the dropdown list works for an embedded image:

@jura.khrapunov → / @ok4p1 → / @vadim.hirbu → could any of you please update the issue description with a proper list of steps for reproduction? Otherwise, it's hard to tell the issue status until it's unclear what the exact expectations were. Thanks in advance!

Now tested: when upgrading from 1.0.14 stable to 1.1.x dev version, after running $ drush updb no any error messages appear on the /admin/content/media page.

The screenshot inserted into my comment on GitLab does not appear here on D․org, so pasting here its link: https://git.drupalcode.org/project/acquia_dam/-/merge_requests/90#note_4...

Added 🐛 Php warnings after update to 1.1.0-beta5 Active to the list.

Root cause found which is quite a lame coding mistake, actually: our 2 field definitions with different types (File / Image) both received the same field storage definition (source code):

Tomorrow morning I will open a merge request including the fix together with some minor improvements as well.