I also tried updating the Common module (which the Log docs say to make sure to install first before installing Log) to 3.4.56 (from 3.4.54) before trying to update Log to 3.4.23, but with either version the error is the same when I select Log ‘Update’ from the module admin page:
Fatal error: Cannot declare trait Common\TraitModule, because the name is already in use in /home/digita40/public_html/omeka-s/modules/Common/TraitModule.php on line 53
I’m still having a problem updating the Log module. I recently tried updating to the latest 3.4.25 from both the standard .zip and also from the source code version. After the updated module is copied in place when I click ‘update module’ I get a blank screen. This is under Omeka 4.1.1 with PHP 8.3.14. I also tried on one of our servers running Omeka 4.0.4 and PHP 8.2.9 with the same result (but there I don’t have access to an error_log file).
I’m still able to run Log 3.4.21 but not able to update further. See error below (from error_log):
[12-Dec-2024 20:42:39 UTC] PHP Fatal error: Cannot declare trait Common\Log\Formatter\PsrLogAwareTrait, because the name is already in use in /home/digita40/public_html/omeka-s/modules/Common/src/Log/Formatter/PsrLogAwareTrait.php on line 5
Maybe it’s a simple fix or something I’m missing in the update procedure? I’ve tried disabling the module first but uninstall fails through the Omeka Module admin UI (blank screen), so I just manually remove the older version and copy the new one in place and update but that hasn’t made any difference.
I did try removing the old Log version completely by De-Activating and then Uninstalling - which failed – and so I removed the directory by hand, so to speak, and Omeka then complained about the module still being in the database but not on the filesystem).
re. Common: I didn’t technically ‘Uninstall’ (from the menu option) Common, although I did remove the directory before copying over the latest version. That’s an idea.
@carlj , I was thinking that sometimes, if you upload the updated module, there could be changes to the files, and an old file might conflict with a new one. I’ve seen that happen before and the easy fix is to remove all of the files in the corresponding module directory.
If this were the problem, I wouldn’t think you would need to completely uninstall the module or even deactivate it in the Omeka admin interface.
As a side note, you can deactivate modules by toggling the is_active column in the modules table if you have access to the database.
@fackrellj Good to know about going into the database table and toggling the is_active column. Haven’t needed to try that but making a note. There has been the occasional issue (although not recently) when I’ve deleted a module and the database has stubbornly refused to remove references to the module. I’ve always gotten around that in various ways (or let it slide, or updated to a newer Omeka version) without touching the mysql database directly.
I’ve never had to deactivate a module before updating but thought I’d try it (earlier today) but it didn’t make any difference. I avoid copying a new (updated version) module on top of an old for exactly the reasons you mentioned.
@carlj , sorry I’m not sure I can help then. I did some testing with the latest version of Omeka S and the Common and Log modules and I don’t see an issue. I even tried installing Log 3.4.21 first and upgrading to Log 3.4.24 and there were no issues.
Ah, well, good to know that it’s working, and that much is confirmed. Some oddity with my setup perhaps. I might try uninstalling Common and trying again.
That’s helpful info, nonetheless. More than I knew previously.
@carlj I would suspect that you have another module (which might not be Log) that contains the “Common” classes, and both of them getting loaded is what’s causing your problem.
I’d suggest running the following command on your server to list all copies of TraitModule.php within your modules folder. First move to your installation’s modules folder, then run
And on our omeka.net (/var/www/html/modules) it only returns:
./Common/TraitModule.php
As mentioned, haven’t been able to upgrade Log on either and the errors are pretty much identical. In the case of the reclaimhosting server should I try temporarily disabling Robots and see if that makes any difference?
On our reclaimhosting.net test instance, removing the Robots module did (yay!) allow the upgrade to Log 3.4.25 to succeed. I then reinstalled the Robots module and that seems to have gone ok as well.
So partial success, at least, and thanks for the suggestion.
I haven’t yet tried uninstalling/reinstalling Common on our omeka.net instance(s).
Just glancing around, looking from the outside at these modules, it does look like the combination of Robots carrying its own copy of Common as a Composer dependency and how Log loads the Common classes could cause this kind of problem.
There’s a check here in Log designed to avoid loading the Common “PsrLogAwareTrait” if it’s already loaded, but it won’t work correctly because the thing it’s loading is a trait, not a class, so it needs to be using the function trait_exists.
Under normal usage this problem doesn’t really have visible effects since require_once is used to load these files, which will only load a given file once. But if Robots is present with its additional copy of Common, it becomes possible for the same class or trait to get loaded twice, leading to the type of errors you’re seeing. Whether the error happens will depend on which module loads first, which is why your uninstalling/reinstalling worked, but that’s not the most consistent fix.
Changing the call I highlighted to be trait_existsmay be enough to fix the problem on its own. But a change to Robots so it relies on Common being installed alongside may be a better answer. Or of course if you have server access to simply add a robots.txt file, you might prefer to do that rather than have the module.
Thanks for the additional comments on possible reasons for conflicts with the Robots module and Log.
We don’t have Robots installed on either of our hosted mit.edu instances that are also having the same name already in use problem but pointing that out maybe something I can try…
I’ve been able to upgrade to Log-3.4.25. In my final two instances, one where I had the Robots module installed, I removed Robots, installed Log 3.4.25 successfully and then reinstalled Robots. Finally, on our production instance where the Robots was not installed I tried again and the 3.4.25 upgrade worked without a problem this time.
Not totally sure what happened in the final example that went smoothly this time, but all is OK so I’ll take it.
I removed dependencies to module Log on all modules i manage, so normally it won’t be occur any more. But Common is required in many places instead, in particular for the PSR-3 mechanism that simplify translations and logging and that is not implemented.
