Sorry, all -

I know I have been here before, but I need help desperately. I am trying to upgrade a site from 8.5.6 to at least 8.5.8, if not 8.6.2, but every time I try it dies. I did NOT build this site with composer. I cannot go back and rebuild it at this point, as it is already 2 years old, and my boss will not allot the time. Period. The ONLY error that is filling my Apache log for the site looks something like this:

Error: Class 'Brightcove\\API\\Client' not found in /var/www/sadsite/htdocs/modules/brightcove/src/EventSubscriber/BrightcoveInitSubscriber.php on line 22 #0 [internal function]: Drupal\\brightcove\\EventSubscriber\\BrightcoveInitSubscriber->initializeBrightcoveClient(Object(Symfony\\Component\\HttpKernel\\Event\\GetResponseEvent), 'kernel.request', Object(Drupal\\Component\\EventDispatcher\\ContainerAwareEventDispatcher))\n#1 /var/www/sadsite/htdocs/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\\Component\\HttpKernel\\Event\\GetResponseEvent), 'kernel.request', Object(Drupal\\Component\\EventDispatcher\\ContainerAwareEventDispatcher))\n#2 /var/www/sadsite/htdocs/vendor/symfony/http-kernel/HttpKernel.php(127): Drupal\\Component\\EventDispatcher\\ContainerAwareEventDispatcher->dispatch('kernel.request', Object(Symfony\\Component\\HttpKernel\\Event\\GetResponseEvent))\n#3 /var/www/sadsite/htdocs/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\\Component\\HttpKernel\\HttpKernel->handleRaw(Object(Symfony\\Component\\HttpFoundation\\Request), 1)\n#4 /var/www/sadsite/htdocs/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\\Component\\HttpKernel\\HttpKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#5 /var/www/sadsite/htdocs/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\\Core\\StackMiddleware\\Session->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#6 /var/www/sadsite/htdocs/core/modules/page_cache/src/StackMiddleware/PageCache.php(184): Drupal\\Core\\StackMiddleware\\KernelPreHandle->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#7 /var/www/sadsite/htdocs/core/modules/page_cache/src/StackMiddleware/PageCache.php(121): Drupal\\page_cache\\StackMiddleware\\PageCache->fetch(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#8 /var/www/sadsite/htdocs/core/modules/page_cache/src/StackMiddleware/PageCache.php(75): Drupal\\page_cache\\StackMiddleware\\PageCache->lookup(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#9 /var/www/sadsite/htdocs/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\\page_cache\\StackMiddleware\\PageCache->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#10 /var/www/sadsite/htdocs/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\\Core\\StackMiddleware\\ReverseProxyMiddleware->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#11 /var/www/sadsite/htdocs/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\\Core\\StackMiddleware\\NegotiationMiddleware->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#12 /var/www/sadsite/htdocs/core/lib/Drupal/Core/DrupalKernel.php(666): Stack\\StackedHttpKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#13 /var/www/sadsite/htdocs/index.php(19): Drupal\\Core\\DrupalKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request))\n#14 {main}

But ALWAYS starts with "Error: Class 'Brightcove\\API\\Client' not found in /var/www/sadsite/htdocs/modules/brightcove/src/EventSubscriber/BrightcoveInitSubscriber.php on line 22"

I *know* that the people in charge of this module insist upon Composer. I know it is the wave of the future and everything. I promise to use composer in the future, but if anyone out there could help me figure out how to get past this so I can update and be secure, I would be very grateful.

I have the Brightcove module set up like this:
Brightcove Brightcove (brightcove) Module Enabled 8.x-1.3
Brightcove Brightcove Proxy (brightcove_proxy) Module Enabled 8.x-1.3
Brightcove Media Entity Brightcove (media_entity_brightcove) Module Enabled 8.x-1.3

I made sure I was on PHP-API-Wrapper version 1.1.0. I am running everything on an Ubuntu 16.04 box with PHP 7.0.32.

Thank you so much in advance.

CommentFileSizeAuthor
#17 ludwig-integration-3009048-17.patch318 bytesdevad
#16 3009048-ludwig-support-1.patch300 bytesjan.mashat

Comments

justkristin created an issue. See original summary.

jan.mashat’s picture

jan.mashat commented
Title: Brightcove, Missing API Client (say the apache logs but NOT the D8 Status Report) , and broken update to 8.5.8 » Error: Class 'Brightcove\\API\\Client' not found
Status: Active » Closed (works as designed)

The reason you're getting the error is because by omitting `composer install` you're failing to autoload the library:

https://github.com/brightcove/PHP-API-Wrapper/blob/master/composer.json#L27

What that does is add the library to autoload like so:

vendor/composer# grep -B2 -A1 -in "Brightcove" *.php
autoload_psr4.php-89-    'Composer\\Semver\\' => array($vendorDir . '/composer/semver/src'),
autoload_psr4.php-90-    'Composer\\Installers\\' => array($vendorDir . '/composer/installers/src/Composer/Installers'),
autoload_psr4.php:91:    'Brightcove\\Test\\' => array($vendorDir . '/brightcove/api/test/Brightcove/Test'),
autoload_psr4.php:92:    'Brightcove\\' => array($vendorDir . '/brightcove/api/lib/Brightcove'),
autoload_psr4.php-93-    'Behat\\Mink\\Driver\\' => array($vendorDir . '/behat/mink-browserkit-driver/src', $vendorDir . '/behat/mink-goutte-driver/src'),
--
autoload_static.php-155-        'B' =>
autoload_static.php-156-        array (
autoload_static.php:157:            'Brightcove\\Test\\' => 16,
autoload_static.php:158:            'Brightcove\\' => 11,
autoload_static.php-159-            'Behat\\Mink\\Driver\\' => 18,
--
autoload_static.php-498-            0 => __DIR__ . '/..' . '/composer/installers/src/Composer/Installers',
autoload_static.php-499-        ),
autoload_static.php:500:        'Brightcove\\Test\\' =>
autoload_static.php-501-        array (
autoload_static.php:502:            0 => __DIR__ . '/..' . '/brightcove/api/test/Brightcove/Test',
autoload_static.php-503-        ),
autoload_static.php:504:        'Brightcove\\' =>
autoload_static.php-505-        array (
autoload_static.php:506:            0 => __DIR__ . '/..' . '/brightcove/api/lib/Brightcove',
autoload_static.php-507-        ),

This is not something I would recommend adding manually, therefore you should really switch to a composer-based install.

As composer is clearly required by PHP-API-Wrapper (the first Installation note is: You have to run composer install before using the library.) I'm going to dare and say that this works as designed - but please know that you can always re-open the ticket if you have further questions.

justkristin’s picture

justkristin commented

I have to say that I am tired of this "one way or the highway" answer. Also, it is not merely throwing an error. It is killing the whole site - nothing shows up at all.

For those in the same boat, here's a TL;DR of Jan's answer:
“We, the developers, have decided that Composer, is the ONLY way to install anything. Those of you who built your sites earlier than this major push to Composer, regardless of whether your site has been up and live for years, are simply going to have to rebuild if you want to use Brightcove. Can’t/Won't help you. Works as designed.”

I doubt highly that I am alone in not using composer with D8 – in fact I *know* I am not. Please tell me that this is not our only option. A great majority of modules are still installable without composer, and many can be installed in multiple ways. Seems to me that this insistence on Composer is a symptom of developer reticence…

Dammit, I hate writing angry things, but I hate even more being repeatedly told that there is only one way of doing a thing when I *know* there is not. Come on, guys. I said that I can't rebuild - I have no control over this use of my time. I came asking for help, not yet another slapdown. :(

justkristin’s picture

justkristin commented
Status: Closed (works as designed) » Active
jan.mashat’s picture

jan.mashat commented
Status: Active » Postponed (maintainer needs more info)

I wasn't aware that there is a native way to autoload libraries in Drupal 8 without using composer - can you please provide some references to this method you speak of?

It seems that many other projects would benefit from this information as well, for example:

justkristin’s picture

justkristin commented

Jan,

I am not a developer. If I were, I would not need to ask for help. However, I do know that I am able to install modules that require external libraries, and I do so by installing the library in a libraries directory somewhere in the Drupal install. If it has become impossible for modules to find required libraries this way, it is news to me. If, however, this is a different type of library requirement, simply explaining that, and perhaps coming up with possible solutions other than "works as designed; closing" might be a bit friendlier. I came in asking for help a number of times now; each time I had problems, the answer was always "use composer. Works as designed. closing." No consideration was given to anyone who may have started a site, now live, without composer. Jan, not all of us have teams full of devs. I am the single web dev (as sad as that may seem to you) - I am alone doing anything behind the HTML/CSS in my company, and I am not given much time for ANYTHING, let alone rebuilding sites. I mentioned this initially. I came to you this time requesting help, and yet you gave me the same answer: "use composer. Works as designed. closing." I *know* I was able to use previous iterations of the Brightcove module, with the API Wrapper library simply put in the libraries folder, so I am confused as to why this needs to change now. I just wanted help - I stated this as well in my initial post. "use composer. Works as designed. closing" is not help. It is washing your hands of a situation. At the very least, should the missing library NOT bring down a whole site?

Seriously, can anyone suggest something? Someone who cares? "Use composer. Works as designed. closing," is barely better than Amazon product question responders who say, "I don't know. I have never used it that way." :( If I can't figure something out, we will have to remove the module and include videos manually, which is fine, except it looks like removing the module is also nigh on impossible...

justkristin’s picture

justkristin commented
Status: Postponed (maintainer needs more info) » Active
jan.mashat’s picture

jan.mashat commented
Title: Error: Class 'Brightcove\\API\\Client' not found » Installation without composer
Category: Support request » Feature request
Status: Active » Needs work

Kristin, I'm not sure if you've seen the issues I've referenced above - but all of them are asking how to install libraries for various modules without using composer, and all of them have been "Closed (won't fix)" by the maintainer.

You keep insisting that we are taking unilateral actions by requiring composer, but we are simply following Drupal's best practices.

That being said, I may have found a solution for you: https://www.drupal.org/project/ludwig

mmjvb’s picture

mmjvb commented

No, you are not following best practises! You are following the worst practice I've ever seen. One of the rules in release management is to not take something away. When providing a `better` alternative you allow the user to pick the new way or the old way. Once the new way is battle tested you can deprecate the old way. Never just swap them. But you are right in saying that is practice in Drupal. Not caring about its users and force new ways down their throat, neglecting their circumstances.

How embarrassing that one of your users needs to tell you how things were done before composer. And yes, Ludwig can be a solution, at least when you provide a ludwig.json. Would consider that beyond the capabilities of the users. That is when Ludwig still needs that and can't distill it from the composer.json.

justkristin’s picture

justkristin commented

That did the trick, at least for now. Thank you for that, Jan.

mmjvb: I have to agree. I feel as though there was no backwards-compatibility offered, no choice in the matter for those who didn't have the wherewithal to learn a new system *and* rebuild a site, simply to keep using a module they'd already been using. For anyone else wondering, I used the following as my ludwig.json:

{
  "require": {
    "brightcove/api": {
      "version" : "v1.1",
      "url": "https://github.com/brightcove/PHP-API-Wrapper/archive/1.1.0.tar.gz"
    }
  }
}
mmjvb’s picture

mmjvb commented
Title: Installation without composer » Installation with Ludwig instead of composer
jan.mashat’s picture

jan.mashat commented

Kristin, I'm glad that helped - but I'm still wondering how nobody found this solution in the issues I've referenced above (and probably many others). If you'd like to contribute, feel free to submit a patch and change the Status to Needs Review.

mmjvb, is it safe to assume that you've opened a ticket in the core project to address this issue? Or if you feel that this project could have handled the transition to composer better (with a limited budget), can you please elaborate?

mmjvb’s picture

mmjvb commented

It is save to assume these tickets already exist. It bad to assume this is something exclusive for core. As mentioned it is contrib that forced this upon us, not drupal itself! Nothing wrong with the introduction of composer for core. The problems are with abusing composer to start managing your site code base. Definitely not what it is intended for! By now it is well known where it lacks and work is done to fix these issues.

And again you are asking things you already know. The previous versions provided the information required, for years. Removing the information about dependencies, hiding them in a composer.json and not providing a ludwig.json are all signs of bad maintainership.

As far as this issue is concerned the information is provided and should be reviewed. Bonus points for adding it to the software but documentation should suffice. Which is why I changed the title so people can find the information.

justkristin’s picture

justkristin commented

Jan -

I didn't find an answer because I was searching based on the log error I had, which did not make clear what the cause of the error was. As far as I knew, the library was in place, because it always had been. I had even upgraded based on the requirements in the documentation. I was confused as to how a not-technically-missing library for a single module could bring down a whole site, but nothing in the logs said to me that if the library wasn't *now* installed with composer, the entire site would go down...

I am still grateful for the Ludwig tip, but wouldn't a more graceful failure also be something to consider? It seemed as though the fault for this issue was being placed entirely with me for not adopting a single method to do a thing, and I can't think that this is good business or community-building procedure... I would love to help with patches, if I had the time and the skill. I might start with simply adding the ludwig.json file I created above...

You said that the decision to create this module with only a Composer install method was not unilateral, so I am going to also advise our BrightCove account folks that, if *they* commissioned this module requesting that it ONLY work with composer, that this may not be the right way 'round. It seems to me that it is not unlike a web agency that gets rid of support for not only the least used browsers, but all browsers but the single newest versions.

Anyway, thank you again for your assistance.

jan.mashat’s picture

jan.mashat commented

I meant that it wasn't this project's decision to require composer - that requirement came from Drupal.
Have you seen the issues I've referenced above with other projects having the same exact predicament?

jan.mashat’s picture

jan.mashat commented
Status: Needs work » Needs review
StatusFileSize
new 3009048-ludwig-support-1.patch300 bytes
devad’s picture

devad commented
Title: Installation with Ludwig instead of composer » Brightcove Video Connect - Add Ludwig integration
Version: 8.x-1.3 » 8.x-2.x-dev
StatusFileSize
new ludwig-integration-3009048-17.patch318 bytes

Hi Brightcove Video Connect module maintainers

I am a Ludwig module co-maintainer.

Here is the patch so that we support all Drupal users who are not familiar with command line tools like Composer yet (or want to avoid it for other reasons).

ludwig.json file is updated to mirror current composer.json file.

I have tested it and it works fine with Ludwig.

devad’s picture

devad commented

The latest Ludwig 8.x-1.1 has full brightcove/api library support.

Is it possible to commit #17 and make a new Brightcove Video Connect module release - to add Ludwig integration to Brightcove Video Connect module officially?

yce’s picture

yce commented
Status: Needs review » Closed (works as designed)

Thank you for the patch, unfortunately I would rather not add it to the module as it would go against the basic workflow on how the modules, dependencies and library should be handled.
It would be a bad practice to introduce something that is not recommended.

The recommended way is to use composer so we are supporting only that.

devad’s picture

devad commented

Thank you for reply @yce.

The Ludwig integration is officially created by Drupal Commerce project and implemented inside dozens of modules in Commerce Ecosystem.

During the time Ludwig evolved into the solid Composer alternative for Drupal contrib modules with library dependencies in D8/9 environments. Ludwig integration is added officially to 15+ contrib projects.

Despite the common saying that "everybody is using Composer nowadays", Ludwig module has a surprisingly steady weekly project usage increase ever since it is created in mid 2017 up to today. So, there are still a lot of users around who are not familiar with composer yet... and they are eager to use Drupal as well... if we support them to do so.

In the case of Brightcove Video Connect module, the integration in simple and straightforward (patch #17).

The maintenance is very simple... the ludwig.json file should be kept in sync with composer.json file only. It is a minimal effort for maintainers.

If you as a maintainer stick to your decision not to add Ludwig integration to the Brightcove Video Connect module officially, that's ok of course.

Those in need to manage this module without Composer can apply the patch #17 manually still - and manage it with Ludwig.