Module updates, but still shows need to update

[selwynorren]

Hi All,

So I have an interesting one. Brand new install (Downloaded this morning and installed v1.5.1 for PHP 8.1. It shows, BeesBlog, CoreUpdater and Block Newsletter need to be updated. So do the normal run of updating them, however the back office still shows it needs to be updated. When I look at the file in the modules folder. It seems it has been updated. Just back office is not recognizing it.

Is there perhaps a specific PHP module that I may be missing?

[selwynorren]

6 minutes ago, selwynorren said:

Hi All,

So I have an interesting one. Brand new install (Downloaded this morning and installed v1.5.1 for PHP 8.1. It shows, BeesBlog, CoreUpdater and Block Newsletter need to be updated. So do the normal run of updating them, however the back office still shows it needs to be updated. When I look at the file in the modules folder. It seems it has been updated. Just back office is not recognizing it.

Is there perhaps a specific PHP module that I may be missing?

Just to confirm. It defiantly does execute the update of the module. Example coreupdater.php now show 1.6.6 instead of the reported 1.6.5. If it updated any other files I have no idea.

There is also no error_log generated and if I activate debugging, no errors are produced either.
 

I have also cleared browser history and all cache and cookies aswell

[the.rampage.rado]

Did you try clearing your caches?

[selwynorren]

1 minute ago, the.rampage.rado said:

Did you try clearing your caches?

Thanks yup I did indeed.

[the.rampage.rado]

And no bueno?

Sometimes this happens and it's cache related issue, either the thirtybees cache is not working correctly or the browser cache is fuzzy...

[selwynorren]

13 minutes ago, the.rampage.rado said:

And no bueno?

Sometimes this happens and it's cache related issue, either the thirtybees cache is not working correctly or the browser cache is fuzzy...

Yeah that was my initial thought, which as I stated I cleared cache, history cookies and everything. The update works, but teh back office does not detect it, so it just keeps saying to update the module

[nickz]

3 hours ago, selwynorren said:

The update works, but teh back office does not detect it, so it just keeps saying to update the module

Do you use a Cpanel hosting? Look for Nginx cache and empty that.

[selwynorren]

4 hours ago, nickz said:

Do you use a Cpanel hosting? Look for Nginx cache and empty that.

Thanks I do indeed, but I use apache and not Nginx. I am also convinced its a cache thing. Let me see if there is some wayward caching module installed in cPanel that I am missing

[nickz]

4 hours ago, selwynorren said:

Thanks I do indeed, but I use apache and not Nginx.

 

I'd look like that. The cpanel uses usually some kind of cache. Most lof the time it's Nginx on the right hand corner halfway down.

Edited December 22, 2023 by nickz

[selwynorren]

6 hours ago, nickz said:

 

I'd look like that. The cpanel uses usually some kind of cache. Most lof the time it's Nginx on the right hand corner halfway down.

Thanks, I definitely don't have that. I do not have Nginx installed

[the.rampage.rado]

12 hours ago, nickz said:

 

I'd look like that. The cpanel uses usually some kind of cache. Most lof the time it's Nginx on the right hand corner halfway down.

Nice widget but nginx is definetly not default configuration on most cpanels.

@selwynorren, did you try different browser?

[selwynorren]

Howdy, Yeah I have tried in Firefox (Good ol Faithful), chrome and Brave and I have teh same results in all three. So that means its definitely not a caching issue, but for sure either server configuration, or small bud.

I have the same version installed on a different server, and that doe snot use php 8.1 and I don't have the issue at all

[selwynorren]

Just now, selwynorren said:

Howdy, Yeah I have tried in Firefox (Good ol Faithful), chrome and Brave and I have teh same results in all three. So that means its definitely not a caching issue, but for sure either server configuration, or small bud.

I have the same version installed on a different server, and that doe snot use php 8.1 and I don't have the issue at all

Just to also say, I had initially install the 7.4 version, but theme deleted the entire catalog and installed the 8.1 version

[selwynorren]

On 12/23/2023 at 5:27 PM, selwynorren said:

Just to also say, I had initially install the 7.4 version, but theme deleted the entire catalog and installed the 8.1 version

Just a quick update on this issue. I downgraded my store to TB 1.4.0 (Still Same server and same php8.1 settings) and now the module reflect the correct updates. This must mean there is an issue on the 1.5.1 installation?

I will try upgrading it to 1.5.0 and see if it still replicates itself

[selwynorren]

5 minutes ago, selwynorren said:

Just a quick update on this issue. I downgraded my store to TB 1.4.0 (Still Same server and same php8.1 settings) and now the module reflect the correct updates. This must mean there is an issue on the 1.5.1 installation?

I will try upgrading it to 1.5.0 and see if it still replicates itself

1.5.0 does exactly the same

[the.rampage.rado]

Last thing I can think of is clicking on the double arrows. Does it clear this page's cache and does it show correct information afterwards.

It's very hard to replicate such edge cases as this is probably some server related issue as many users are already on 1.5 and post 1.5 and they don't report such issues as of now.

[selwynorren]

30 minutes ago, the.rampage.rado said:

Last thing I can think of is clicking on the double arrows. Does it clear this page's cache and does it show correct information afterwards.

It's very hard to replicate such edge cases as this is probably some server related issue as many users are already on 1.5 and post 1.5 and they don't report such issues as of now.

Hmm Which double arrows do you mean? This cannot be a server issue as I literally downgraded to 1.4.0 on that exact same installation and it works, yet the moment I upgraded again to 1.5.0 it stops working. Same as 1.5.1

I have found other cases as well, however I reported that on GitHub and created a solution which I just need @Traumflug to test if its viable.

[donMilorad]

I had the same problem with the Core Updater module.

I managed to solve it with git.

These are steps:

1. Navigate to  /thirtybees_directory/modules.
2. Remove your module.
3. git clone the newest version of the module.

My module is now updated.

Still, this did not solve the problem of updating modules, but its a workaround for core thirtybees modules.

Edited April 3 by donMilorad

[selwynorren]

Yup so I double checked again today, no opcache installed at all, and I uninstalled data mining for statistics module and then re-installed it, now the back office is calling for this module to be updated. In the back office its showing version 2.0.3 however the files itself is version 2.0.4. So clearly the modules are updating, but its not reading the correct module version of whats installed.

I am not 100% sure how it works, however I had a look on the database in the modules table and i see statsdata module showing 2.0.4 which is indeed the latest version. So in the database I manually changed it to 2.0.3 and then ran the module update again, never changed it in the database at all and module still shows it needs to be updated, however files reflect the correct version

I then went and changed the version number in the statsdata.php to an old version number and then ran the module update again, the version number was updated again, yet the back-office shows the incorrect version number.

Now here is where it got very interesting. I deleted everything inside that module folder except the stasdata.php, ran the module update, it re-downloaded everything and then for the first time showed 2.0.4 in the back office I also looked in the database and it updated there correctly as well. So this means there is something in the module folder that was not updating. So I looked at the next module giving me the same issues, which was the html block module. so I looked at tbhtmlblock.php and it showed the correct version number, however the config.xml file showed what my back office was showing. I delete that file, ran the module update and voila, it updates perfectly.

So somehow the back office was reading this xml file but when updating it was not updating this file at all. No idea why, however after deleting the file, running the update, it worked perfectly.

As a final test I changed the config.xml module version back to an old number, ran the module update and we are back to the first problem. So at the core of it all, this config.xml file is not being updated at all. his is causing all the headaches we are experiencing

I hope this helps someone struggling with the issue. You are not going mad, your system is kinda broken, but finally figured out a short term fix. We just need to figure out why this is not updating the xml file

[datakick]

18 minutes ago, selwynorren said:

You are not going mad, your system is kinda broken, but finally figured out a short term fix. We just need to figure out why this is not updating the xml file

I strongly believe the problem is not in the system, but somewhere in your tooling.

Thirty bees core uses config.xml files inside module directory as a cache mechanism, in order to avoid loading module main php file into memory, just to find out basic information about module (name, version, etc)

This cache file is loaded only when following conditions applies:

• config.xml file exists
• config.xml modification time is older than modification time of module primary php file

related code https://github.com/thirtybees/thirtybees/blob/ef47fe6bc88d7cea713e27f91d6f469695b20217/classes/module/Module.php#L798

So, if you download new version of module from thirty bees repository, or if you upload zip file, or upload files directly using ftp client, then module main php file should be overwritten --> its modification time should be newer then modification time of config.xml --> config.xml should not be read but should be regenerated. This is how it behaves on all system I've seen so far.

I believe you that you have these problems, but I don't think the issue is in the code.

The situation that you are describing could happen, for example

• if you change modification time of config.xml to the future
• if ftp client you use to upload files incorrectly set modification time
• if you have some (security or whatnot) tool that touches files and thus changes their modification timestamp