I have a strange issue on a site I am working on. This morning I went to do a composer install and got the following error.:

- Installing drupal/blog (dev-2.x 1830b99): Cloning 1830b9954b from cache
- Applying patches for drupal/blog
https://www.drupal.org/files/issues/blog-no_results_text-2834732-2.patch (Enter drupal/blog patch #2834732 description here)
Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/blog-no_results_text-2834732-2.patch

[Exception]
Cannot apply patch Enter drupal/blog patch #2834732 description here (https://www.drupal.org/files/issues/blog-no_results_text-2834732-2.patch)!

Looks like drupal/blog was updated and the below patch is now included in the module. However, it's strange since drupal/blog is tagged to a specific commit (43a2171) in wxt. However, when I do my site (based off wxt) it is pulling the latest (1830b9954b). It appears like the "upstream" (from wxt) requirement isn't being followed and it is pulling the latest.

Here is the blog issue with comment that it's now in the module https://www.drupal.org/project/blog/issues/2834732#comment-13534423

In my site composer.json I added a the require entry for the blog (the same as in wxt) and it seems to be working.

I am wondering if I need to mimic all "hard tags" in the highest level composer...

Comments

natew created an issue. See original summary.

natew’s picture

natew CreditAttribution: natew as a volunteer commented

It appears from the following composer docs that tagging to git hash isn't really recommended or supported. It also isn't followed if it isn't in the root composer file.

is also a root-only feature and will be ignored in dependencies.

from https://getcomposer.org/doc/04-schema.md#package-links

I am wondering if we can get the blog module to tag a release and we can then pin this in wxt and not have to replicate it in sites that require wxt.

Edit to add.: here is a link to composer docs that also say tagging to a hash isn't really recommended.

joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented

yes we have stumbled on this as well.

joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented

Someone please ping the blog module maintainers and pester them until they release a tagged release, that is what I normally do,
if they refuse, then I usually try to become maintainer going through the project ownership process, usually something happens along the way or someone wakes up.

joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented
Priority: Normal » Major
d8simon’s picture

d8simon CreditAttribution: d8simon commented

Would you be able share what you had to add?

In my site composer.json I added a the require entry for the blog (the same as in wxt) and it seems to be working.

joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented

ok I looked into this a bit more, I think what @natew is trying to say is something like this:

diff --git a/composer.json b/composer.json
index f503d51..02a43c1 100644
--- a/composer.json
+++ b/composer.json
@@ -123,6 +123,7 @@
         "composer/installers": "^1.2",
         "cweagans/composer-patches": "^1.6.7",
         "oomphinc/composer-installers-extender": "^1.1",
+        "drupal/blog": "dev-.x#43a2171",
         "drupal/core-composer-scaffold": "*",
         "drush/drush": "^9.0",
         "drupalwxt/wxt": "3.0.8"
joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented

Hmm, that didn't work, still looking at this.

joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented

ok, so the above workarounds didn't work for us, so instead we added our last known working composer.lock file to our repository, removed the git ignore on the composer.lock, now "composer install" is working again but not composer up

natew’s picture

natew CreditAttribution: natew as a volunteer commented

@joseph that seems to be what I did, here is the exact commit.: https://github.com/StatCan/site-ccei/commit/756abedffd9a4512aa96f8196b58...

Note that this has to be at the "highest" level composer.json file. In our case it's at the site (not the profile). You could probably get away with patch ignoring this also. Which I think I may have tried and didn't quite work.

Edit to add, looks like we got a blog tag on April 3rd! https://www.drupal.org/project/blog/releases/8.x-2.0-beta1

joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented

hmm, your composer.json looks very similar to ours

however I noticed that you put this as the last entry

I might have had to flush the composer cache to get this to 'kick in' , I'll try again when I get a chance,

Thanks,

natew’s picture

natew CreditAttribution: natew as a volunteer commented
Status: Active » Fixed

Should be fixed in 3.0.9

https://github.com/drupalwxt/wxt/commit/93544b86c1fbb6358c4028a86be64fb1...

Edit to add if you want to see this working in the CI for the ccei (the previous github commit I sent) see.: https://travis-ci.org/github/StatCan/site-ccei/builds/670223555

  • natew committed 93544b8 on 8.x-3.x 
    fix(blog): Update blog to address #3124528
joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented

Thanks @natew!

joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented

@natew

make sure to update this as well:

https://github.com/drupalwxt/wxt-project/commits/8.x

natew’s picture

natew CreditAttribution: natew as a volunteer commented

@joseph.oldstad What do I need to change in wxt-project? I see no mention of blog in that code base (i git cloned and grepped).

joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented

see this line of code

https://github.com/drupalwxt/wxt-project/blob/3c6676d7d81f673105add4c14c...

When you update wxt you must also update wxt-project

natew’s picture

natew CreditAttribution: natew as a volunteer commented

I haven't tagged a 3.0.9, was going to wait till we get more into this release (fixes, features, testing). Minimally, I would wait till security updates get released today (if there is any that apply to us). This isn't really a show stopper and doesn't require a release for one fix.

joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented

ah ok , makes sense

hmm, 3.0.9 looks like it will have a lot of disruptive changes with media_entity being removed along with other modules. So the slideshow is going to be destroyed then, we're using the slideshow and have some slideshow images. What is replacing media_entity? Is there an upgrade path for slideshow? If not, can we just delete our slideshow images and create a new slideshow with whatever will be replacing it?

last release we noticed issues when the admin_toolbar_search module was removed and it took a while to figure out what was going on.

joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented

we're still in development phase so won't mind deleting the slideshow and re-creating it provided that there's something to replace it with.

natew’s picture

natew CreditAttribution: natew as a volunteer commented

joseph.olstad lets discuss the removal of media_entity in this issue please.

joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented

I updated to the latest wxt dev following the steps outlined here: #3120601: upgrading using the wxt-project composer.json

seemed to work correctly.

joseph.olstad’s picture

joseph.olstad
Primary language French
CreditAttribution: joseph.olstad commented
Parent issue: » #3127965: Can't install Wxt

I'm answering support requests about this due to 3.0.9 not being tagged yet some people (other than us) are also getting tripped up on this.

Since the standard installation procedure is currently broken with any version other than dev, would it be possible to please publish/tag a release 3.0.9?

natew’s picture

natew CreditAttribution: natew as a volunteer commented

I am not sure when we are planning and doing a new release. However, I would point out that there is a work around to this issue, which is to pin the drupal/blog module in the composer.json you run composer on. This would then have to be removed when you move to the next release. Which is pretty typical in the drupal world . Note this is also not a problem if you use the github tarball, not sure if people are even using that. :P

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

jenniferhoude’s picture

jenniferhoude CreditAttribution: jenniferhoude commented

Tried to install this distribution with the new update but still getting the error regarding the blog patch.

"Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/blog-no_results_text-2834732-2.patch

[Exception]
Cannot apply patch Enter drupal/blog patch #2834732 description here (https://www.drupal.org/files/issues/blog-no_results_text-2834732-2.p
atch)! ."

natew’s picture

natew CreditAttribution: natew as a volunteer commented

@jenniferaube can you provide more detail please? I have updated 2 sites based on the distro (wxt) and I am not seeing this issue (going to 3.0.10 in composer.json). You can see this in our CI for one of the projects in the composer install here . It is installing https://ftp.drupal.org/files/projects/blog-8.x-2.0-beta1.zip with no patches as expected. Not sure how/why you are seeing the patch still? What version are you using?