🇨🇭Switzerland @cburschka

quietone → credited cburschka → .

Hi! Sorry for the lack of response early; I'm very happy to share maintainer status for this project as I haven't been able to devote much time to maintaining Drupal projects lately. :)

Cherry-picked and pushed to 4.0.x (with the appropriate version numbers).

6.0.x is currently marked as D10 only (I'll add D11 at some point after D11 is in beta), so for now it doesn't use a logical OR and doesn't need to be changed.

Thank you!

I'll check and port this change to other supported branches wherever needed. As far as I can tell, the double pipe syntax has been recommended since at least 2017, so it should be safe to do this on all versions.

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

Very interesting; I didn't know <th> was usable inside the table this way.

On the BBCode side, I suppose the simplest way to add this to the current implementation would be to allow declaring the first (or an arbitrary) column as the header via an attribute,

Unfortunately the module doesn't generate this HTML directly but rather outsources it to Drupal's table renderer. I suppose the next challenge will be to figure out how to get that to turn individual cells into

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

Parts of this might've been fixed alongside 📌 Create functional test for basic view functionality. Fixed , where the missing schemas were encountered by adding functional tests.

Needs checks for whether there are further plugin settings with missing schemas on the field formatters.

As serial is contrib, this'd be a submodule with a dependency on "serial".

Tricky, but not as much as I feared.

The entity_reference URL belongs to the "extra" values which are not technically fields, and which are emitted depending on checkboxes in the settings form. It would be feasible to create additional settings for some of these values that are conditional on the checkbox being checked.

(Beside the URL, it might be useful to do this with the "Author" field, which is technically itself an entity_reference field but which is impossible to customize via the view-mode. Currently it looks like the "Author" checkbox in the settings doesn't actually do anything, and the "uid" field is always emitted as an HTML string.)

MR 3373 is supposed to have failures, that's the test-only one :D

Thanks for the work!

Pushed to 2.0.x and 3.0.x.

The test-only patch is failing as designed. This looks ready for review.

Unfortunately I don't see an easy way to run tests on the testonly branch without opening a second MR.

Fixed the deprecations.

I've backdated the previous patches into a fork + merge request to work with it more easily.

I suspect the largest problem is the use of file_create_url(), which was replaced with a service in D10.

Pushed and backported to 2.0.x.

Ah, I see. Yes, it makes sense to use the same behavior in the 'id' attribute of EntityReferenceExportFormatter as in EntityReferenceIdExportFormatter.

And pushed. Thanks all!

Backporting to 2.0.x as well.

Huh. I'm surprised we've even been using a #markup array there, instead of just using the same SerializedData object as immediately above. It looks like this is the only place in the entire module where a field formatter can return something that isn't wrapped in SerializedData.

(Git annotations show I wrote this part in the first few days while designing the module. My guess is that the plugin was only created in the first place to handle the case where alt and title attributes needed to be exported, and that this else branch was rarely used.)

Thanks for the patch! I'm going ahead and replacing that section with

      else {
        $elements[$delta] = [
          '#type' => 'data',
          '#data' => SerializedData::create($uri),
        ];
      }

for consistency, which from local testing seems to also fix it.

(Note for future reference: Maybe counterintuitively, the $uri variable here - from the moment it is retrieved from Entity::getFileUri() - is a string, not an instance of Drupal\Core\Url. Just noting that in case core changes that in the future and breaks this.)

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

The [list] tag should automatically become available when you install the modules Extensible BBCode and Standard Tags. If it isn't listed in the tags for your text format, check to make sure the tag is active.

Pushed to 5.0.x!

In order for tests to work, we also have to add a config schema for the views.field.field_export key. Fortunately this schema is basically identical to the views.field.field key from core, so we can alias that.

cburschka → created an issue.

Adding functional tests for this module is going to be a larger effort (eg the lack of config schemas, which may be complicated further by the fact that we are adding views handlers dynamically via an alter hook).

I am therefore pushing the fix now and leaving test coverage for a separate issue.

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

This is the patch, but it absolutely needs test coverage.

cburschka → created an issue.

2.0.x will not support Drupal 10. 3.0.x compatibility with Drupal 10 is managed in 📌 Automated Drupal 10 compatibility fixes Active .

Reopened to accept new patches for future core versions if needed.

Committed the unit test changes (the file_create_url() changes were already added).

2.1.x is dead, long live 3.0.x.

I haven't touched this module in a while, and am currently trying to relearn the structure.

I see there is already rest_views_revisions submodule with an entity_reference_revisions_export field formatter that its PHPdoc comment claims "exports the rendered entity" of an entity_reference_revisions field.

Does that one not fulfil the functionality needed here? As far as I can tell, the inheritance chain here is:

- core EntityReferenceFormatterBase (ERFB) is the base class for entity reference formatters.
- core EntityReferenceEntityFormatter (EREF) extends ERFB and is the base class for displaying entity reference as rendered entity.
- rest_views EntityReferenceExportFormatter (ERXF) extends EREF.
- entity_reference_revisions EntityReferenceRevisionsEntityFormatter (ERREF) extends EREF.
- rest_views_revisions EntityReferenceRevisionsExportFormatter (ERRXF) extends ERXF, *and* simultaneously wraps an instance of ERREF, as an adapter. It does this to delegate the ::prepareView() call to entity_reference_revisions' ERREF (similar to what this patch copy-pastes into the main ERXF), while allowing its actual parent ERXF to handle the ::view() call.

This probably needs to be backported to 4.0.x, because the strict return types were in there as well.

Pushing the fix. This should pass.

Pushing a test-only patch. This should fail.

Correction, the issue has always existed when returning Filter::tips() as a string instead of Markup. This was introduced by #3207134: Add strict types to xbbcode → , which in a twist of dramatic irony does mention "methods which can return strings or MarkupInterface" as a potential obstacle, but fails to recognize that Filter::tips() is such a method.

Due to PHP silently casting the return value to string in methods that are hinted as string (instead of triggering a type error), this was not previously discovered.

Well, this was a wild goose chase :D

After inexplicably finding this same behavior as far back as 8.6, I finally realized the issue is in my test module: My actual module here returns the result of a \Drupal::service('renderer')->render() call, rather than a string. The renderer, of course, returns a Markup object, which allows the markup and styles to pass through unscathed.

The regression therefore was not in core - it was caused by adding return type hints in my module.

Drupal\filter\Plugin\FilterInterface::tips() asks for the return type to be "string|null" in PHPDoc, and without type-hints, this polite suggestion causes no problem when returning a Markup object.

If we add string as a strict type hint, though, PHP helpfully converts the Markup object back to string before returning it, causing it to be sanitized. :D

In summary, in core this seems to be just a documentation issue for now - all such methods that expect render output should mention Drupal\Core\Render\MarkupInterface as a possible return type alongside string. Eventually as strict type hints get introduced in core (see 🌱 [Meta] Implement strict typing in existing code Active ) this could become more critical.

On testing further, it does seems to affect a lot of markup besides style - for example, one of my macros should do the following:

Turn this

[spoiler]Hidden text[/spoiler]

into the output of this twig template:

{% set id = random() %}
<input id="xbbcode-spoiler-{{ id }}" type="checkbox" class="xbbcode-spoiler" />
<label class="xbbcode-spoiler" for="xbbcode-spoiler-{{ id }}">{{ tag.content }}</label>
{% endapply %}

with this CSS attached:

input.xbbcode-spoiler:not(:checked) + label.xbbcode-spoiler,
input.xbbcode-spoiler:not(:checked) + label.xbbcode-spoiler * {
  color: black;
  background: black;
}
/* Hide the checkbox. */
input.xbbcode-spoiler {
  display: none;
}

This works normally in content:

<input id="xbbcode-spoiler-1375131070" type="checkbox" class="xbbcode-spoiler">
<label class="xbbcode-spoiler" for="xbbcode-spoiler-1375131070">Hidden text</label>

But (in 10.0.2) the sample output on /filter/tips removes everything except the text of the label:

Hidden text

Class and data attributes I tested seem to go through, but they're not really usable in this context. I suppose the markup could be inserted dynamically by a script, but that seems an overly cumbersome way to circumvent the filter.

cburschka → created an issue.

This issue appears to have already existed in 9.4.8.

cburschka → created an issue.

Perfect.

Added the fix. This should pass.

Opened MR with test-only. This should fail.

This has no test coverage because (1) we don't have any empty tags in XBBCodeFIlterTest, and (2) even if we did, prepared tag elements are only used by plugin processors, the only plugin processor used in testing is Drupal\xbbcode_test_plugin\XBBCodeTestPlugin, and this plugin's ::prepare() method returns {prepared:{$content}}, which is never an empty string.

cburschka → created an issue.

The square brackets wrapping the tag name aren't really useful, so I just removed them from the form.