🇩🇪Germany @D34dMan

This patch would fix the image issue in Drupal 10.3 however, will break images below 10.3 :(

D34dMan → created an issue.

Thanks for the MR, it has been merged

I was trying to see if I can fix this issue. While trying to compile the source file, I notice that it tries to build from `modules/mercury_editor_inline_editor` as well. But looks like it is safe to ignore that?

D34dMan → created an issue.

D34dMan → changed the visibility of the branch 3456288-too-few-arguments to hidden.

D34dMan → changed the visibility of the branch 3456288-too-few-arguments to hidden.

D34dMan → created an issue.

D34dMan → created an issue.

After studying this task I see this could greatly enhance the user experience.

To move this forward here is my proposal,

1. Add support for accepting string translations via Yaml Plugin definition
2. Add support for accepting "plural" translations via Yaml Plugin Definition
3. Introduce new Translation service with a higher priority than our Default translation service, but lower than Custom String Translation servicwe, which would provide translation from Yaml definitions (for singular as well as Plural)
4. Add support to "export" translation as PO files, with options to include "custom" translation in the exported PO files or not.

Preferably Point #3 can be implemented via a sub module so that it can be turned ON/OFF as desired.

D34dMan → created an issue.

D34dMan → created an issue.

D34dMan → created an issue.

@xurizaemon,
What is the latency that you experience if you use purge_processor_cron?

For example if you run cron every 10 mins, and 10 minutes is defined as "SLOW"/high latency, then you can benefit from "purge_processor_lateruntime" almost instantaneous invalidation event.

D34dMan → created an issue.

Thanks for the contribution, fixed!

Thanks for diving into the this.

So I guess we could just add a note to Config Overlay's project page about this issue and tell people to upgrade Config Ignore to get rid of this warning.

+1. This should be enough and the issue can be closed. I am satisfied with the explanation and gives me peace of mind that we can ignore the message.

Maybe we could also add an explicit Composer conflict for this version, so people are forced to be running with the new Config Ignore version. On the one hand that seems a little heavy-handed just to avoid an incorrect warning, on the other hand the integration test coverage is already only running with the newer version, so we are at least not testing with the older one.

Adding to composer can lead to un-explicable misery for those who are already using config_ignore 2x. As far as the message goes, its just mis-leading. It doesn't break anything.

@mkrizaj,

The patch in #5 is same as the one posted in #1, could you explain why?

D34dMan → created an issue.

D34dMan → created an issue.

D34dMan → created an issue.

Reduce noise

visual update

Added architecture notes

WIP

Remove related content

Improve related content

Uploaded screenshot and path for download POT files.

Ready

Remove detailed examples

Move detailed usage instruction from the overview page

WIP

Update examples and definitions

WIP

WIP

wip

WIP

WIP

WIP

D34dMan → created an issue.

Not going to pursue this any further for now. Token support needs the parameter to be injected in the source as follows,

Ref: https://www.drupal.org/documentation/modules/token →

$node = node_load(10);
$message = token_replace($unprocessed_message, array('node' => $node))

This goes against the DX planned for the module where the format on how the strings are consumed in source code shouldn't change much.

Thanks for the suggestion and work on this @stmh and @SolimanHarkas.

I am wondering if providing translation should be part of this module. Drupal.org already suggest a way to provide translation via PO files as described here https://www.drupal.org/community/contributor-guide/reference-information... →

Could you please list the pros and cons of doing it via *.string.yml ?

Just a note for the future

17 | ERROR | [x] TRUE, FALSE and NULL must be uppercase; expected "FALSE" but found "false"

This was false warning and fixing that broke the JavaScript code, because 'FALSE' is invalid in JavaScript.

This was fixed in 2.1.2 release that was made recently.

Thanks for the contribution.

Thanks for the contribution.

Thanks for the contribution, much appreciated.

Based on the guidance from Tobias (@tstoeckler) who pointed out that using getLoadedrevisionId api in node update might identify the parent revision correctly.

D34dMan → created an issue.

Thanks for the contribution :)

If that works for you, then its a good start.

Now to do it in a maintainable way, you can follow the recommendation in this tutorial on how to override a template file https://www.drupal.org/docs/7/theming/overriding-themable-output/beginne... →

@drupaler99,
The order of the fields displayed could be controlled from here '/admin/structure/types/manage/pmproject/display'

Regarding how you could theme the icons, do you know how to create a custom theme and override templates?

Hi @ drupaler99, could you please provide a screenshot of what and where you are trying to accomplish?

In case you are talking about the links on Dashboard, those are implemented (hardcoded) in module. They are not editable using Drupal's Admin interface. When the relevant module gets enabled, the links are automatically made available.

It is possible to override them using a preprocess function inside a custom theme. An example for this can be found in pm_kickstart_theme

https://git.drupalcode.org/project/pm_kickstart_theme/-/blob/7.x-3.x/tem...

function pm_kickstart_theme_preprocess_pm_dashboard_link(&$vars) {
  module_load_include('inc', 'pm', 'includes/pm.icon');
  $link = $vars['link_blocks'];
  $vars['fa_icon'] = pm_helper_get_fa_icon($link['icon']);
  $vars['href'] = check_plain(url($link['path']));
  $vars['href_add'] = FALSE;
  if (isset($link['add_type']) AND $link['add_type']) {
    $vars['href_add'] = url('node/add/' . check_plain($link['add_type']));
  }
  elseif (isset($link['extra_link']) AND $link['extra_link']) {
    $vars['href_add'] = url($link['extra_link']);
  }
}

This needs work. We need to recognise tokens that can be present in string and provide replacements while it is rendered. This maybe already taken care by the translation system, we need to check that.

Fixed, as new MR's created from now onwards would have live preview available.
E.g. https://www.drupal.org/project/string/issues/3283328 📌 100% Test Coverage Active

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

@ arnoldbird thanks for the detailed report. I was able to reproduce this in my local as well as uploaded a fix to latest branch.

Un-fortunately this won't fix the configuration issues in sites where pm has already been installed. Even though it possible to fix the issue in a hook_install, Documentation about hook_uninstall states that we should not remove configuration in a hook_install.

Ref: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension...

In short, you should still experience the problem with old installations, and procedure to recover is already mentioned in the Issue description and comment #3.

We need to also support partial decoupled scenario, where Decoupled app is served by Drupal in some inner page. This could be as simple as setting "credentials true" in the fetch application, but would be nice to have a public api for this.

Thanks for testing, marking this as RTBC :)

TypeScript vs JavaScript with JSDocs for Types

TypeScript has loads of benefits which can outweigh some shortcomings or dis-pleasures I encounter now and then :P.

E.g., for supporting web and server from same codebase, we need often need to load correct method/library based on platform on which the code is being executed. Such support needs dynamic typing, which is quite complex to achieve in TypeScript. Example, using native fetch if available when in web environment, vs some library. Same goes for localStorage and other platform specific quirks.

I have not tried JavaScript with JSDocs for types, but looks like it would help me at least not bother about such un-necessary work-arounds when we need dynamic Typing.

---

For Authentication Support, created this issue for following it up https://www.drupal.org/project/api_client/issues/3365476 →

D34dMan → created an issue.

D34dMan → created an issue.

@Deciphered, practically couldn't this be handled by having multiple instance of client created for the said purpose?

There has to be some sort of session support (thinking about authentication) that needs to be managed for a client to be really useful. Otherwise we limit the client to interact as anonymous user or rely on being served in such a way that cookie based session is carried on.

I do agree that it doesn't make sense to start from scratch.
At the same time, for a long term success, we should reduce the dependencies as much as possible. Especially when dependencies brings in their own bunch of dependencies which are not under our control.

I suggest we design a clear user friendly API for our client. We can use orbit.js or something similar under the hood though. This can later evolve into a plugin based architecture that helps you swap the transport layer if needed. But having a normalised API would help develop and maintain other parts that depends on the client, which is the 'main' goal if you ask me.

D34dMan → created an issue.

Am also interested in maintaining the project and also have capacity to do so.

Thanks for testing, reporting and providing fix @allisonc. I have committed the code to 4.1.x-dev branch

sub module `string_i18next` accomplished this feature.

Thanks for the contribution :)

D34dMan → created an issue. See original summary → .

Could not find a matching version of package npm-asset/fonticonpicker--fonticonpicker. Check the package spelling, your version constraint and that the package is available in a stability which matches your minimum-stability (stable).

could you please try to change "minimum-stability": "stable", to "minimum-stability": "dev", in your composer.json and try again?

To know more about minimum-stability and its implication, please check out documentation on https://getcomposer.org/doc/04-schema.md#minimum-stability

Updated the format for code snippet for curl request in the end to use code block, instead of inline style.

D34dMan → created an issue.