I think time has come to prepare new release compatible with D11.
There is still an error in modules/contrib/cleantalk/lib/Cleantalk/Custom/Db/Db.php according to Upgrade Status module in line 18:
Call to deprecated method tablePrefix() of class Drupal\Core\Database\Connection. Deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Instead, you should just use Connection::getPrefix().
> We plan to release a new version in January 2024.
Thank you for quick response.
> We will check our module within 5 business days
Still no new version?
Still no new version?
Still no new version?
@ eugene_p can you provide a new stable version?
The error messages still appear in unpatched 9.3.2.
@znaeff, what updates are you waiting for here when you have sent users to use your private ticket system?
I've upgraded from 9.2.6 to 9.2.7 - now without any error.
It means that warnings above are only due to incompatibility of 9.2.6-9.2.7 code with database tables prior to 9.2.6. Update process still needs post-upgrade handling.
@znaev, it IS reproducible, because it has been reproduced at least by 5 independent users. The fact that maintainers can't reproduce it means only one thing: that maintainers can't reproduce it.
Does version 9.2.7 provide any "update db" procedure?
PPS. And there's another one minor bug: the version 9.2.3 in admin interface on Cleantalk site has't changed to 9.2.5. Five days left.
I'm here with some results.
1. First I tried to exclude any "cache issues" when standard upgrade process occurs via composer update drupal/cleantalk. Hence, I've flushed all caches not only after upgrade, but before too via drush cr. It didn't help - I've got these 3 warnings on local machine again (noticed that they repeates every 3 minutes).
2. Because full testing of Cleantalk module can be performed only on production site special care should be taken if something will goes wrong and one can revert changes very fast. So I've applied the following procedure:
3. All cofigurations files on local and remote (production) machines were syncronized between databases and local configuration folders.
4. Then, on local machine I've uninstalled module via /admin/modules/uninstall page. Fortunately, only two configs changed in site database: 'core.extension' and 'cleantalk.settings'. Uninstall procedure removes all tables cleantalk* in database (with one exception, see below) as well.
5. Then, via standard procedure: composer update drupal/cleantalk, drush cr and after update drush cim to restore module installed with saved configuration.
Nice result: now there is no errors in watchdog. And all tables have restored in database.
6. On this stage we can more or less safely apply this on production site. I've pushed/pulled composer.lock via git to production site and have applied the above "uninstall-update-install" procedure (we need to use composer install, of course). Well, no errors in watchdog and all module settings remained intact.
Conclusion.
Because with standard update procedure all database tables stay intact and uninstall/install procedure recreates them, it can be concluded that the cause of the bug is incompatibility of some old table content or maybe of tables structure itself with new version of php code.
Maintainers need to provide some "update db" procedure that makes required changes in database table. Of course, it is "breaking changes" (along with moving temporary sfw folder in new location), so it is better to make a new MINOR version of Cleantalk.
PS. There is one table, namely 'cleantalk_ac_ua_bl' that isn't removed by uninstall procedure, but it's content is deleted. It is one more small bug in deinstallation process.
@Glomberg, thanks a lot for advice.
I'm going to make some experiments.
I will write back to you within 3 business days when I get any results :)
@znaeff, I've replied you many times: I can't give you administrative access to production site. And nobody, I think.
You have to find some other way to fix issue.
@znaeff, there are at least three independent cases where this bug have been met. What is the reason to hide additional info behind private support system?
It looks like update procedure should have some post-update handler to change something in configuration.
By the way, what environment have you used when reproducing the issue (Drupal version, PHP version, etc.)?
My are: Drupal 10.1.2 and PHP 8.1.21.
Warnings appear regardless of whether SFW is enabled or not.
I don't think that uninstalling/installing method is a right way to fix issue. At least it looks like that 9.2.5 release is incompatible with previous releases. So you need to release a new MAJOR version of Cleantalk (and point out this incompatibility) or provide a way to upgrade between two PATCH versions without total module removing.
Had same warnings after upgrade. Reverting back to 9.2.3.
The problem has been solved one year ago https://github.com/Leaflet/Leaflet/issues/5705. I think we can close the issue, checked as described here https://www.drupal.org/project/leaflet/issues/3103941 → , the bug disappeared.
_kom__ → created an issue.
@znaeff, looks like txt icon, not a patch.
@itamair, thanks, now it works perfectly.
There is still a small issue when Scale Control is in the bottom-left corner, but it is not the subject of current issue.
@Orkut, 1)create two different map bundles, 2)create two different node types with geofield in each represented by these different bundles, 3)disable Scale Control for all bundles in Leaflet settings (or maybe for one). Will all other controls enabled (except +/- buttons) stay in place?
Did anybody test this new feature with Lealet Layers installed and more than one map bundle created?
The are some issues for me, but I can't decide if they are Leaflet 10.0.14 release issues, Leaflet Layers issues or maybe even known Drupal core JS bugs.
I've found that directory cleantalk/cleantalk_fw_files is created by webserver only for a few seconds, then server deletes it. But now I've got
Warning: file_put_contents(/var/www/drupal/public_html/modules/contrib/cleantalk/cleantalk_fw_files/index.php): Failed to open stream: Permission denied в Cleantalk\Common\Firewall\FirewallUpdater->prepareUpdDir() (строка 714 из /var/www/drupal/public_html/modules/contrib/cleantalk/lib/Cleantalk/Common/Firewall/FirewallUpdater.php)
I think that is also due to improper location of created directory and the reason is that files/folder owner and webserver are not the same in my case.
However, further consideration is out of this issue, I'll create a new topic for this special case.
@znaeff, hope you'll find appropriate and secure solution.
I have given all necessary permissions to Cleantalk module folder and for cleantalk_fw_files folder, but there is still no files in it. And SpamFireWall still doesn't work: there is again no records in dashboard.
Should I create support request via my account? Maybe something went wrong on your side?
@ znaeff it is absulutely clear, the question was why you select so unfavourable place for storage? There is a lot of practical solutions for such folders in Drupal core (js, css or php/twig folders) or in wide range of contributed modules (see, for example Asset Injector or Color modules). All these use common default/files folder.
Yes, it helps to disable/enable firewall and changes configuration. But.
It is a very bad practice to enable webserver write permissions in any Drupal place except specially allowed (e.g. sites/default/files/). Please, look here
https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... →
.
Moreover, it can cause Composer integrity issues when local changes take place in directories that are under it's control.
What is the role of this folder? What files will appear there? Is there any special reason to put them in module directory?
Today I've renewed my subscription to extended package (AntiSpam + Security) and found that SpamFirewall still doesn't work (no log messages in Dashboard, bruteforce attacks still appear in Watchdog).
I've noticed that SpamFirewall checkbox in Cleantalk settings is still turned on (it was turned on for years when previous subscription was active).
So I've tried to "reload" configuration on my side via unchecking/checking again this checkbox.
Disabling of SpamFirewall proceeded after click on "Save" button, Settings page reloaded and checkbox became unchecked (of course, active module configuration changed).
But. After trying to re-enable SpamFirewall I've got mentioned above error - and one more warning:
Warning: mkdir(): Permission denied в Cleantalk\Common\Firewall\FirewallUpdater->prepareUpdDir() (строка 705 из /var/www/drupal/public_html/modules/contrib/cleantalk/lib/Cleantalk/Common/Firewall/FirewallUpdater.php)
After reload of Settings page checkbox remained unchanged, active configuration (with disabled SpamFirewall) too.
So I had to import old saved configuration to return system in previous state.
Please, show me the right way: what shall I do and how to make SpamFirewall work:
- Use the suggested patch
- Try to reinstall module
- Stop using Cleantalk and totally remove all it's code from my computers :)
Thank you.
My environment is: Cleantalk 9.2.3 and Drupal 9.5.9.
Looks like maintainer had Drupal activity two years ago...
Should be reopen, because there is no release version.
@Orkut Murat Yılmaz thanks for this link, looks great.
I've got the similar warnings when I've tried to mount 'drupal' folder on the host via nfs+bindfs plugin into guest machine managed by Vagrant+Virtualbox. Mount configuration is:
config.vm.synced_folder "drupal", "/vagrant-nfs", type: "nfs", nfs_udp: false
config.bindfs.bind_folder "/vagrant-nfs", "/var/www/drupal",
u: 'vagrant',
g: 'vagrant',
perms: 'u=rwX:g=rwD',
o: 'nonempty'
config.nfs.map_uid = Process.uid
config.nfs.map_gid = Process.gidVagrant and www-data are members of both groups 'vagrant' and 'www-data'.
On the other hand, there is no warnings when using native vboxsf with same user:group:
config.vm.synced_folder "drupal", "/var/www/drupal", owner: "vagrant", group: "vagrant"
No errors observed on production server with totally same configuration: Drupal 9.5.8, Ubuntu 22.04.2
PHP 8.1.18, Apache 2.4.52 with another 'sysadmin:sysadmin' user and no mount directories.
Can maintainers prepare a new release with this simple patch? It looks like everything is OK.
@Wim Leers, so what about 9.5.x branch?
I've got the same bug on 1680 px width screen (two rows splitting of toolbar with overlapping page header).
Not fixed in 3.0.1.
The simplest way to reproduce (I can't put it into issue description, because I'm not author of this issue).
1. Upgrade module to 3.0.1
2. Open /admin/config/entity-type-clone and select any node type, e.g. Page
3. Assign Target bundle name 'Page Clone' and Target bundle machine name 'page_clone'
4. Click 'Clone' button
5. Go to /admin/config/development/configuration
6. There will be a lot of created configurations (depends on fields that you have added earlier to node type Page). Every configuration has the row 'uuid: ...' except -
7. Open 'core.entity_form_display.node.page_clone.default' - it has NO 'uuid: ...' row.
See example above:
langcode: ru
status: true
dependencies:
config:
- field.field.taxonomy_term.volosti_kaz.field_guberniya
....And correct exported config should be:
uuid: 00091558-3256-4dae-ac66-49f9cb058eed
langcode: ru
status: true
dependencies:
config:
- field.field.taxonomy_term.volosti_kaz.field_guberniyaDid you try to reproduce it on single Dupal installation?
You must have TWO Drupal sites (e.g. development and production) - one for export configuration of cloned entity and another for import this configuratoin. When configuration file (namely, "...form_display...") is imported in other installation it gets uuid in Drupal database automatically because this field is missed in imported configuration file. As a result, configurations remain unsynchronized with DB because imported file has no row with uuid and hence they are different.
Of course, when you try to do export/import on single Drupal installation you can't see differences, because both configurations (in database and exported file) has no uuid.
I don't know how to explain this simple fact more clear.
As a temporary workaround you can lower PHP version but this is NOT "Drupal 10 ready" solution.
By the way, I do not see announced feature "role clone" neither in 2.0, nor in 2.2 release. Can you point out commits in commit log that fix these?
Not fixed in 2.2.0 in /config/sync/core.entity_form_display.taxonomy_term...
Looks like fixed in 2.2.0
Not fixed in latest release 2.0
Not fixed in latest release 2.0.