🇺🇸United States @bas123

bas123 → created an issue.

bas123 → created an issue.

bas123 → created an issue.

slowflyer ,

Thank you for the explanation. Obviously, it is better to wait for the Open Social developers to correct the issue!

zartab farooquee → ,

Your recommendation:
SHOW CREATE TABLE activity_notification_status
Returned the following:

Your SQL query has been executed successfully.

SHOW CREATE TABLE activity_notification_status;
activity_notification_status	CREATE TABLE `activity_notification_status` (
  `u...	

I can add a primary key using the PHP MySQL function under "More", which create the same code you provided and the same result:

ALTER TABLE `activity_notification_status` ADD PRIMARY KEY(`uid`);
MySQL said: Documentation
#1062 - Duplicate entry '3' for key 'PRIMARY'

This still shows in the Drupal Status page as:

The following table(s) do not have a primary key: activity_notification_status, user_activity_digest, user_activity_send

From the database:

Drupal Version: 10.2.9
Installation profile: Social (social-12.4.5)

I have the following similar issue:

Transaction isolation level
READ-COMMITTED
For this to work correctly, all tables must have a primary key. The following table(s) do not have a primary key: activity_notification_status, user_activity_digest, user_activity_send

The error references: https://www.drupal.org/docs/system-requirements/setting-the-mysql-transa... → , however that page provides information on changing the transaction isolation level, but nothing about setting the primary key

While I do have access to PHPMyAdmin and thus the database in order to set primary keys for those listed tables, I do not know which field to set for each!

For example, in the 'activity_notification_status' I tried to set the 'UID' as the Primary Key, but this was the response...

SQL query: ALTER TABLE `activity_notification_status` ADD PRIMARY KEY(`uid`);
MySQL said: Documentation

#1062 - Duplicate entry '3' for key 'PRIMARY'

So, if that is the case, why would the Drupal Status Report show this error?
And how would one resolve this?

bas123 → created an issue.

UPDATE: My Case was resolved via the Hosting Provider, A2 Hosting (Advanced Tech Support

Here's how:

The apc.shm_size setting can only be adjusted in system-level ini files, so I had to create a special configuration file to update the setting:

*SERVER*@az1-ls2 [~]# cat /etc/cl.php.d/alt-php83/custom.ini
apc.shm_size = 64M

https://YOURWEBSITE.net/info.php now shows 64MB of memory. Please let us know if there are any other issues we can help with.

My Status Reports no longer show the error and actually reflect the correct APCU Settings

PHP APCu available caching: Memory available: 45.48 MB.
PHP APCu caching: Enabled (64 MB)

Drupal Version: 10.3.2
PHP Version: 8.3.9 - Memory limit: 4G

As others above, this error has been present through several recent updates of Drupal Core and other key modules, but always resolved after clearing caches, however since updating to D 10.3.2, it doesn't go away!

I asked my hosting company to increase this limit to 64 MG and they complied with no hesitation.

Their method was to add the following line to the document root (public_html) folder's .htaccess file.

php_value apc.shm_size 64MB

However, my Status Report still shows the same error:

PHP APCu caching
Enabled (32 MB)
Depending on your configuration, Drupal can run with a 32 MB APCu limit. However, a 32 MB APCu limit (the default) or above is recommended, especially if your site uses additional custom or contributed modules.

What is the latest with Drupal 10 compatibility?

Or should I abandon this module before upgrading?

bas123 → created an issue.

@jcnventura → ,

You can probably fix that by exporting the configuration and then searching for filter_adsense, and removing that line from the text formats, and then re-importing configuration. Or add adsense back to the system, and run drush en adsense to re-enable the module.

I searched my site via Control Panel search and in three instances of my site: "Production" (Drupal 9.5.11), "Development 1" (Drupal 9.511), "Development 2" (Drupal 10.1.6) which is crashed in the front tend and parts of Admin, "filter_adsense" does not show up anywhere.

Also, on the Development 2 site, I do not have access to CKEditor5 configuration for Full HTML (same Adsense errors) which would be the likely candidate for locating any references to "Adsense Filters", and when I view in Development 1, where I do have access to Full HTML, I do not see any references there anyway.

I installed your version via composer require 'drupal/adsense:^1.4@RC' and confirmed through the info.yml that the module reflects Drupal ^10 compatibility.

However, when I try installing the three modules:

• AdSense
• AdSense ads.txt
• AdSense pre-2007 code

I cannot install:

Prior to taking steps to become Drupal 10 ready, with all three installations, I had multiple blocks with "raw html codes" (Not CKEditor), for Google Adsense IFrame Codes, and do not recall using the Adsense modules other than the one that holds my Google Adsense Account number. (AdSense ads.txt ???)

I have the option of working with the two development sites online (No local capabilities) and have tried multiple methods of reversing the problem before utilizing a surefire methods on Production.

To be honest, I do not see how this module is of any use and am happy to remove it unless someone can demonstrate its value.

Either way, it seems to be the biggest stumbling block to moving into Drupal 10.

Any thoughts are appreciated.

Can someone please summarize this solution?

If I am reading the patch correctly, all it is doing is to change the video_embed_facebook.info.yml to reflect "core_version_requirement: ^8 || ^9 || ^10"

If that is the case, why cannot one simply edit the file directly?

If the additional solution includes the steps listed in #11 📌 Automated Drupal 10 compatibility fixes RTBC , then that is easy enough too.

My only goal is chipping away at a number of module obstacles that are preventing me from moving my site into Drupal 10!

@Larowan → , I just wanted to make you aware of the following error that shows up in a development site that I managed to update to Drupal 10 (but with significant errors)

Errors found
Transaction isolation level
READ-COMMITTED
For this to work correctly, all tables must have a primary key. The following table(s) do not have a primary key: forum_index. See the setting MySQL transaction isolation level → page for more information.

.

bas123 → created an issue.

I can only tell you that it is not compatible with Drupal 10!

I thought I had uninstalled it from a Drupal 9 site and went forward and updated my site to Drupal 10 and now it is crashed on the front end, meaning no content will display and many of the Administration pages as well are displaying the following error:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "filter_adsense" plugin does not exist. Valid plugin IDs for Drupal\filter\FilterPluginManager are: editor_file_reference, entity_embed, filter_caption, filter_autop, filter_null, filter_html, filter_html_escape, filter_image_lazy_load, filter_url, filter_html_image_secure, filter_align, filter_htmlcorrector, media_embed in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

And I have unable to restore the site or re-enable the Adsense module!

Also, it may be that other (non Drupal 10 ready) modules that update.php required I remove may also cause this error state once the Adsense issue is resolved, but that remains to be seen!

I am open to any response that might help me resolve this issue because I have multiple Adsense Ad positions that may or may not be affected as well. In short, I do not know whether or not my Production site, which is dependent upon the Adsense Ads will even work in Drupal 10 without this module.

bas123 → created an issue.

bas123 → created an issue.

bas123 → created an issue.

bas123 → created an issue.

When a distribution shows the latest version as lets say: XXYYZZ.15.11.0

but after running #composer update -W the resulting version is marked as XXYYZZ.15.11.x-dev, is it safe for the Production website?

Or must we wait until XXYYZZ.15.11.0 is ready?

I ask because I have been unable to do a local development since Acquia discontinued Dev Desktop and have never pushed from a local machine to a Production environment. Therefore, I run multiple stages of development sites in subdomains on my hosted account and then recreate the desired changes in Production once they are ready. 

So, just as long as I can better understand all of the version numbering sequences, I should be safe, yes?

Thank you in advance for any insights!

I just updated to Social (social-11.8.12) and the ugly Default Profile image wouldn't display once again and I couldn't get any of the patches to work until I tried #84 🐛 Image field default value not shown when upload destination set to private file storage Needs work ( 2107455-84.patch → )

At least for now that one solved it in four Drupal Open Social websites! so Kudos to Jan Kellermann → !

I just wish this problem which has persisted for several years and incarnations would ge committed to core...

bas123 → created an issue.

bas123 → created an issue.

bas123 → created an issue.

@RgnYLDZ → If you look at the list of excluded words, I/they provided, any files with those wildcards are not backed up. In my case, the wildcard was *cache*.

I doubt that they fixed that for what should be obvious reasons as the exception list comprises words that they feel (especially with WordPress sites) are not essential to the functioning of the CMS and therefore will slow down the process of backing up all of their account holder's websites on a daily basis

However, if you are having issues with the Jetbackup utility in their cPanel, I recommend that you open a ticket and explain the problem. If the answers are not satisfactory, then ask that your issue be referred to an Advanced Tech Support Specialist and reiterate that the issue is not CMS related but has been caused by the backup utility they provide.

A2's tech support and primary focus is on WordPress users and accordingly, their front line support staff primarily is trained in that CMS. Typically, you must work with the more experienced support specialists in order to get answers from someone knowledgeable in Drupal.

Addnl note: I have now installed this module on 5 development versions of my Production site, all of which are running Drupal version 9.2.21
with Open social version social-11.3.16.

The module was installed using Composer using the require command and then updated with composer update -W, so there should be no conflicts beyond that!

The error code is consistent as above!

Would like to add that in lieu of being able to use the UI to configure Reroute Emails, per the readme file, I did add:

/**
* Set Reroute Email to send or not to Admin
*/
$config['reroute_email.settings']['enable'] = TRUE;
$config['reroute_email.settings']['address'] = 'administrator@website.com';

to the settings.php file, and that does seem to be functioning so far via some tests!

So the issue must be something to do with the form configuration in the UI for the module!

bas123 → created an issue.

@dalemoore → , thanks for that specific correction.

Saved me a support ticket! 😁

@webhostuk →
I believe it is a cPanel/WHM Server due to the fact that I have two accounts (different servers) that I have access to via the main login screen.
These accounts are accessed via separate cPanel Logins

Here is the server information:

Hosting Package Turbo Max 2020
Server Name az1-ts5
cPanel Version 110.0 (build 8)
Apache Version 2.4.57
MySQL Version 10.3.36-MariaDB-cll-lve
Architecture x86_64
Operating System linux
Perl Version 5.16.3
Kernel Version 4.18.0-372.19.1.lve.el7h.x86_64

bas123 → created an issue.

I am reopening because the issue is significant and still persists (at least in version social-11.3.16), and that it wasn't addressed by anyone from the Open Social team.

To see the images cropped so badly in favor of the comments when viewing an album image on smaller devices is simply amateur and turns viewers away from the Open Social website.

Additionally, my recommendations as to further developing the album feature so each image could allow infdividual commenting has also not been addressed!