Migration module wants to install 1.0.1

[hubbobubbo]

I am about to press the button but my newly installed migration module says it is going to install 1.0.1. It should say 1.0.2 by now right?

[hubbobubbo]

Update2:

I have asked my hosting provider if they have an installation of geoip running by default. That might explain the duplicated defines and functions.

However, I now am back to the previous problem. I did the update to 1.0.3 and now I have the same error. The problem is that even if I remove the function, the site keep complaining about the same problem on the same line, like this:

Fatal error: Cannot redeclare geoipcountrycodebyname() in /var/www/vhosts/myhost.com/update.myshop.com/vendor/thirtybees/geoip/src/geoip.inc on line 1602

I have removed the function on line 1602 but it keeps complaining about the same thing. So, again, Plesk has caching disabled. Is it possible that the php file is cached somehow by TB? If so, how can I clear that. Right now even if I change the geoip.inc file, the changes does not bite, it keep complaining about line 1602.

[hubbobubbo]

@mdekker thanks for the fast reply. I am making progress so lets see if I can make it happen. Let me ask two things:

1. When you say disable geoip. Do you mean from the side of my hosting? Or can I do it somehow in TB?

2. Can you give any advice on why it seems that changes to geoip.inc are not detected even though I have removed the offending file the error keeps complaining about the same line as before. Do note that in 1.0.1 it started to work when I commented out this function but now after updating to 1.0.3 even if I remove the function again, the change is not detected. It is like the php file is cached or something?

I really do not care about this geoip support so if there is a simple way to remove it from TB I would love to try. As you say, it is a super old project and if it causes problem I rather purge it.

[hubbobubbo]

I found the reason for the changes not working.

In 1.0.3 you have changed the geoip folder from vendors/geoip to vendors/thirtybees/geopip so I had 2 instances of the geoip code and I changed in the old location.

I will ask my hosting provider what can be done but are you really sure that this is not something that can be improved on the TB side? Several other posts have had the same type of problem with other applications than Prestashop and it mainly seems to affect function geoipcountrycodebyname and geoipcountrynamebyname

Some posts suggest wrapping these functions in something like this: if (!functionexists('geoipcountrynameby_name')) { } taken from this site: https://www.drupal.org/node/2221205

I guess that might be problematic if you fetch from github but given that this project has not been updated in years you might just be ok with your own fork offering the extra protection for your users?

Just trying to ensure a smooth process since right now any updates will probably break by shop if my local changes are overwritten. Having this protection by default or a way to enable the geoip support only on demand from TB would remove future issues similar to mine (I hope :-)

[hubbobubbo]

@mdekker my hosting provider confirms that geoip is available by default on the servers and this is not something that is configurable. They say to simply disable the module using it.

So, I really do not know what geoip offers to ThirtyBees but it does not seem that impossible to get to a solution for this? I am no expert and I do not know how and for what you use geoip but I have never missed not having it so maybe it could be considered that TB either: - Forked the geoip repo and add if (!function_exists(‘)) protection so your clone works even if the hosting has geoip as well. - Makes the dependency of geoip optional for TB users so the system does not break if the hosting provider already has geoip installed.

[hubbobubbo]

@mdekker I think we are misunderstanding each other. Let's see if we can take a step back and get to a solution for this.

I am on a shared hosting, the largest official Prestashop host in my country. They have geoip pre-installed on their servers and it can not be disabled on a per account basis. The conflict must be solved on application level, i.e. we must fix it or anyone wanting to install TB on a similar setup will fail if the hosting provider has geoip pre-installed. This appears to be a common issue affecting not only Prestashop but Drupal and other PHP applications as well.

Again, I am not an expert but solving this seems fairly straight forward. In ThirtyBees we must prevent that these function clashes with a pre-installed version of geoip on the hosting. As far as I can see, this can be solved in two ways:

1. You provide a way to turn off geoip support in TB. Maybe with a define or something else.
2. You fork the geoip repository and wrap these functions inside a if (!function_exists(‘)) check so that they are not exposed if they are already available on the hosting.
3. Based on this post https://www.akeebabackup.com/support/admin-tools/Ticket/9904-php-fatal-error-cannot-redeclare-geoip-country-code-by-name.html it seems as it may be even simpler to wrap the require call to check if geoip already exist rather then changing the geoip.inc file. Maybe you just have to do something like: if(!functionexists('geoipopen')) { requireonce JPATHADMINISTRATOR.DS.'components'.DS.'com_admintools'.DS.'helpers'.DS.'geoip.php';[/code]

in the right place and the warnings will also go away?

Sorry for pushing so hard but this seems a very common problem and without a solution in TB my installations or updates will always break until I manually hack the geoip,inc file and this will likely happen to others as well. It seems the fix is not that complicated.

[hubbobubbo]

Cool, please put a note here once that is ready and I will make a clean migration again to check that it works with my hosting.

Thanks for the help