When running a debugger with VM2 the maximum execution times are not set

[mbarry]

VM 2.0.26a
Joomla 2.5.17

Scenario:
     My development environment is
       XAMPP
       Eclipse (Indigo Service Release 2)
       Server Debugger: XDebug
       Execute Administrator in debug mode
       
     Run the VM2 Migration tool with "everything" selected".
     
Issue:
      The Migration panel shows the following:
        max_execution_time 0
        Server settings do not allow changes of your max_execution_time in the php.ini file, you may get problems migrating a big shop

        On line 46 of helpers/migrator.php the call to ini_get('max_execution_time') returns 0 instead of the value set in php.ini
        Using ini_get_all() we can see that the global_value is same as php.ini however, the local_value is set to 0.
        This is due to the debugger overriding the local_value of 'maximum_execution_time' with value of zero. If set to zero, no time limit is imposed.
       
        While this is okay for most situations, a return value of zero breaks where a percentage of the time allocation is assigned to $this->maxScriptTime

        This occurs in the following places:
          helpers/migrator.php line 49
          helpers/tableupdater.php line 46
          models/product.php line 56
         
        In all cases $this->maxScriptTime is assigned value of -1
     
Solution:
      In each of the above files and below the identified line number insert the following:
        if($this->maxScriptTime == -1) {
           $this->maxScriptTime = 360;  // the value of this number could be set from a global value set from the Migration Panel
           
           Recommend modification to views/updatesmigration/tmpl/default_migrator.php around line 41 to detect for return value of zero and
        set global value based on user input and/or a recommended default value of say 360 seconds.

Affected files:
      administrator/components/com_virtuemart/helpers/migrator.php
      administrator/components/com_virtuemart/helpers/tableupdater.php line 46
      administrator/components/com_virtuemart/models/product.php line 56
      administrator/components/com_virtuemart/views/updatesmigration/tmpl/default_migrator.php around line 41

[AH]

Mbarry

Many thanks for this and your other migration posts!

I had this exact issue in my debugger.

I ended up hardcoding the migrator.php to enable me to debug. (which I will remove once put into live)

But this is a nicer solution!

[mbarry]

Thanks for your reply.

Having gotten so much good information from the forum and seeing the pain others and myself were going through to Migrate from VM1 to VM2, I could see that more automation was and is required. I couldn't justify paying for a 3rd party Migration Tool when VM2 should have it inbuilt for its own tables.

[AH]

I agree - the basic tools are a good start and for many they will be enough.

However it does require some pretty manual processing of some items.

Have you got any idea how to get the vm_product_category_xref  'ordering'  to move.

I think I will have to do this using some of my own sql after migration as this appears to be handled in the product model using code that is not utiltised in the migration.

Damn pity the original product_id is not maintained in the migration else this would be simple to do.

I tried to stop it being changed, but the migration fails :-( and I started to lose teh will to live trying to sort it out LOL.

Again, thank you for taking the time to post your solutions for the benefit of others.