Hi there,
I'm getting errors when I am saving shipment or payment methods, is this just me?
See screenshot
(http://puu.sh/aUQbM/991ab5cabf.png)
Thanks,
Richard
Better to copy paste the error than a screen - does my eyeballs in try to read these with out being able to edit
Is there a #__virtuemart_payment_plg_paypal table in your database - should be created when the method was created
And on all my test 2.9's never seen this
assume the paypal plug is published
Yeah didn't think to copy n paste, I checked my plugs and the VM paypal is published. However when I clicked on the plugin I'm getting the following error (pasted:),
PayPal
vmpayment / paypal
PayPal
Fatal error: require() [function.require]: Failed opening required 'JPATH_VM_ADMINISTRATOR/helpers/shopfunctions.php' (include_path='.:/usr/local/php53/pear') in /home/dir/public_html/mysite/plugins/vmpayment/paypal/paypal/fields/paypalcreditcards.php on line 25
PayPal works fine for me J3.3.3 VM2.9.9 on my test server. No errors.
I'm also 3.3.3 and 2.9.9, might be a conflict between paypal plugs as I have that god awful mijoshop installed on my test site too. Would you like me to pm you an admin user/pass so you could check it out?
I do not do housecalls. Except for our paying clients. Best to test using a vanilla J3.3.3 with only VM2.9.9 installed. No other crap that could cause conflicts.
Jenkhill, I thought this is a bug and considering that I'm helping beta test this could solve future issues thus saving forum and ticket time. I'm 100% sure there will be people that use VM3 on existing sites so surely you want to iron out these bugs before releasing VM3
but as we have both said - on a clean install there is no "bug"
we can't possibly code for the chance someone has some other shop software in their install..
normal practice is not to have a hogwash of a site with scripts and extensions willy nilly installed/unpublished etc
A tidy site == a tidy mind
Hi GJC,
I appreciate you can't code for chances, but I thought the whole point of beta testing was to iron out bugs. Like I said earlier, there is a 100% chance that people will use VM3 on pre-existing installs of Joomla 3 and thus should be looked into. I'm not bothered about fixing the problem if it's to do with a 3rd party extension, but looking into would be a good start. It seems pointless beta testing if you don't even look into attempting to fix the bugs.
Plus wouldn't this be useful in docs if other people run into the same problem? I mean it would probably save a lot of time in tickets and forum posting if you guys know about this and can put something like "Disable X, Y, Z extension if you get error"
Thanks,
Richard
Gringo we understand you, but in your case the error is very strange and points on a non complete VM installation.
It is not an update problem.
Hi Milbo,
Yeah I understand that, just thought if I found any bugs I should report them for investigation. I have found another bug, but I'm not sure if there's any point in posting if it's not going to be investigated.
Thanks,
Richard
it will be investigated if it is a repeatable bug on a clean install
Hi,
I had the same problem.
I investigated a little and I found that it gets to a problem when you have 2 or more joomla pages with same database only with different table prefix.
So in my example I have two joomla pages (J2.5 & VM2.6 and J3.3 & VM2.9) with same database "demo". Only table prefix is different for each joomla.
In vmplugin.php:
protected function onStoreInstallPluginTable ($psType,$name=FALSE)
there is a line
$query = 'SHOW TABLES LIKE "%' . str_replace('#__', '' , $this->_tablename) . '"';
That means it searches whole database without prefix, then it finds table of other VM page and thinks table already exists.
So solution would be to replace #__ with table prefix, not with ''.
Best Regards,
Sandi
Thank you, sounds very valid.
Hi everyone,
I'm new to these forums but I also experience problems when adding shipment methods in VirtueMart administration. I am working on Joomla 3.3.3 and Virtuemart 2.9.9a. The problem is in the statement that creates the XXX_virtuemart_shipment_plg_weight_countries table. The following error is thrown when adding a shipment method using "VM Shipment - By weight, ZIP and countries" plugin:
QuoteIncorrect table definition; there can be only one auto column and it must be defined as a key SQL=CREATE TABLE IF NOT EXISTS `XXX_virtuemart_shipment_plg_weight_countries` ( `id` int(1) UNSIGNED NOT NULL AUTO_INCREMENT, `virtuemart_order_id` int(11) UNSIGNED, `order_number` char(32), `virtuemart_shipmentmethod_id` mediumint(1) UNSIGNED, `shipment_name` varchar(5000), `order_weight` decimal(10,4), `shipment_weight_unit` char(3) DEFAULT 'KG', `shipment_cost` decimal(10,2), `shipment_package_fee` decimal(10,2), `tax_id` smallint(1), `created_on` datetime NOT NULL default '0000-00-00 00:00:00', `created_by` int(11) NOT NULL DEFAULT '0', `modified_on` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `modified_by` int(11) NOT NULL DEFAULT '0', `locked_on` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `locked_by` int(11) NOT NULL DEFAULT '0') ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
It seems that there is no explicit primary key column designation in the SQL statement, the statement fails and the table is not created. Looking in this forum I have found an SQL statement that works to create this table, which simply adds
PRIMARY KEY (`id`) just after the locked_id field declaration.
Is this a bug and a suitable fix? and finally, when do you expect VM3 to be released?
Thank you very much, you are doing a great job with VM3 migration
weird error - I have been working all week on 2.9.9 ship plugins and the tables always create fine for me
they are created in administrator/components/com_virtuemart/plugins/vmplugin.php and the prim key is set
see around line 433 function createTableSQL() - its called on the 1st store of a method
ends
$query .= " PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='" . $tableComment . "' AUTO_INCREMENT=1 ;";
Hi again, I opened the file vmplugin.php and it is as you say, the PRIMARY KEY (`id`) is present, but still having the same error when saving the first shipping method. The SQL statement does not include it and it fails.
Reinstalled VM 2.9.9a again, for the third time yet, the error is no longer shown. It may have been incorrect installation or could it be some kind of cache or update issue?
Thanks again
Glad to see that this is being looked into now, do you guys have any idea how frustrating it is to be told "no we wont look into it" when it was clearly a genuine bug. I felt very let down guys, as I was trying to help.