🇺🇸United States @hanksterr7

Apologies, now that cron has processed more broken links, I am now seeing, on the right side of the broken links report, items like: "Edit node 1965" which allows editing the node that contains the broken link. At first, for most broken links, that section was filled with "This link was not found in any content."

Question: how does a link get into the broken links report if it was not found in any content?

hanksterr7 → created an issue.

Note, the link in the requirements error message takes me to https://github.com/openlayers/openlayers/releases/download//-dist.zip which is a broken link

Ok, thanks. I'll keep an eye on the topics you mention and let you know if I find any php 8.2 problems not addressed by your upcoming fixes

ok, I finally got OL 3.3 installed. Wasn't pretty

Did these steps:
-- uninstalled OL module and all child modules, and deleted the openlayers folder from sites\all\modules
-- disabled fast 404 (since might interfere with registry autoload) and IP Geoloc (since it had an openlayers2 view component) modules (but did not uninstall)
-- deleted all references to openlayers in registry and registry_file tables
-- ran registry rebuild several times
-- installed OL 3.3 module and enabled it. Didn't crash system!
-- renabled OL submodules, IP Geoloc and fast 404

All good

So I know just enough drupal and php to be dangerous :)

I see that
class ServiceProviderPluginManager extends DefaultPluginManager
is defined in
openlayers\src\DependencyInjection\ServiceProviderPluginManager.php

And
sites/all/modules/openlayers/lib/OpenlayersServiceContainer.php
says:
use Drupal\openlayers\DependencyInjection\ServiceProviderPluginManager;
$service_provider_manager = new ServiceProviderPluginManager();

Why is the code not finding the ServiceProviderPluginManager class?

Is there some code I can add around the call to get an instance of the ServiceProviderPluginManager class to test if it exists?

Blah

I ran registry_rebuild. First time it seemed to work ok, but got this error

PDOException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: DELETE FROM {cache} WHERE (cid LIKE :db_condition_placeholder_0 ESCAPE '\\') ; Array ( [:db_condition_placeholder_0] => entity\_property\_info:% ) in cache_clear_all() (line 173 of /public_html/includes/cache.inc).

Ran it a second time and got no errors

Then tried enabling openlayers module but still get this

PHP Fatal error: Uncaught Error: Class "Drupal\openlayers\DependencyInjection\ServiceProviderPluginManager" not found in /sites/all/modules/openlayers/lib/OpenlayersServiceContainer.php:80

hanksterr7 → created an issue.

I will try 7.x-3.2, with service container module disabled

The main page for openlayers still indicates service-container module is a dependency. Should this be changed?

I have a solution (?) to the issue. I doubt this is the right way to fix this, but i offer this if anyone else has similar issues

This function lives in includes\sources.mysql.db.inc

If fetches the tables and views for a "source"

The problem is, it builds a static list of tables for a source. If you have multiple sources that are part of a backup job, and the sources have different tables, the static list built from the first source gets used for the subsequent sources. That causes the wrong list of tables to be looked at when trying to back up the subsequent sources

I reset $tableData to null so it would always get rebuilt when this function is called

Probably could have just removed the "static" attribute

Don't know what unintended consequences there are to this approach, but it now allows me to get all my db's backed up

  /**
   * Get a list of table and view data in the db.
   */
  protected function get_table_data() {  
    static::$tableData = null; // add this
  
    if (empty(static::$tableData)) {
      $tables = $this->query('SHOW TABLE STATUS')->fetchAll(PDO::FETCH_ASSOC);
      foreach ($tables as $table) {
        // Lowercase the keys because between Drupal 7.12 and 7.13/14 the
        // default query behavior was changed.
        // See: http://drupal.org/node/1171866
        $table = array_change_key_case($table);        
        static::$tableData[$table['name']] = $table;
      }
    }
    return static::$tableData;
  }

hanksterr7 → created an issue.

Ok, problem is solved, for me, but it is not a general solution. (I'll describe what worked after this brief discussion -- I offer all of this for others who may run into the same issue)

A general solution would require offering an optional significant implementation change to Domain Access, something I doubt @agentrickard would consider viable. It would require that each subdomain be mapped to its own drupalroot/subdomain folder, instead of just drupalroot.

The subdomain creation tool in my current version of cpanel, found at https://my.bluehost.com/hosting/app/#/domains/subdomains, does not allow specifying public_html to be the home directory of a subdomain. It forces a folder inside public_html to be the home of subdomain.

I found that instead of using the subdomain creation tool, I could simply add an "A" record in DNS settings, pointing to the server's IP address, and that would allow a new DA domain to be created and work.

However, my wildcard certificate was not getting notified that subdomain.example.com exists, so users would get a SSL_ERROR_BAD_CERT_DOMAIN error trying to reach https://subdomain.example.com

I found an SSL/TLS Status applet in cPanel that, through an AutoSSL tool, allows managing all the sites that share my wildcard certificate. All sites created through the subdomain creation tool are listed, but sites created by just adding a DNS settings "A" record do not. If there were a way to tell AutoSSL about my new "A" record, that might also solve the problem. I could not find a way to do this.

I contacted Bluehost a year ago about this and they suggested the "A" record approach. I contacted them again today and this time they let me know the old cpanel subdomain creation tool was still available, at https://my.bluehost.com/cgi/dm/subdomain. With this old tool available, I deleted the DNS "A" record and created the subdomain having its home directory be drupalroot and now the subdomain works properly in Domain Access, including via https

hanksterr7 → created an issue.