Errors saving shipment and payment configs

Started by gringo211985, August 16, 2014, 14:36:05 PM

Previous topic - Next topic

gringo211985

Hi there,

I'm getting errors when I am saving shipment or payment methods, is this just me?

See screenshot


Thanks,
Richard

GJC Web Design

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
GJC Web Design
VirtueMart and Joomla Developers - php developers https://www.gjcwebdesign.com
VM4 AusPost Shipping Plugin - e-go Shipping Plugin - VM4 Postcode Shipping Plugin - Radius Shipping Plugin - VM4 NZ Post Shipping Plugin - AusPost Estimator
Samport Payment Plugin - EcomMerchant Payment Plugin - ccBill payment Plugin
VM2 Product Lock Extension - VM2 Preconfig Adresses Extension - TaxCloud USA Taxes Plugin - Virtuemart  Product Review Component
https://extensions.joomla.org/profile/profile/details/67210
Contact for any VirtueMart or Joomla development & customisation

gringo211985

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

jenkinhill

PayPal works fine for me J3.3.3 VM2.9.9 on my test server. No errors.
Kelvyn
Lowestoft, Suffolk, UK

Retired from forum life November 2023

Please mention your VirtueMart, Joomla and PHP versions when asking a question in this forum

gringo211985

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?

jenkinhill

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.
Kelvyn
Lowestoft, Suffolk, UK

Retired from forum life November 2023

Please mention your VirtueMart, Joomla and PHP versions when asking a question in this forum

gringo211985

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

GJC Web Design

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
GJC Web Design
VirtueMart and Joomla Developers - php developers https://www.gjcwebdesign.com
VM4 AusPost Shipping Plugin - e-go Shipping Plugin - VM4 Postcode Shipping Plugin - Radius Shipping Plugin - VM4 NZ Post Shipping Plugin - AusPost Estimator
Samport Payment Plugin - EcomMerchant Payment Plugin - ccBill payment Plugin
VM2 Product Lock Extension - VM2 Preconfig Adresses Extension - TaxCloud USA Taxes Plugin - Virtuemart  Product Review Component
https://extensions.joomla.org/profile/profile/details/67210
Contact for any VirtueMart or Joomla development & customisation

gringo211985

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

Milbo

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.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

gringo211985

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

GJC Web Design

it will be investigated if it is a repeatable bug on a clean install
GJC Web Design
VirtueMart and Joomla Developers - php developers https://www.gjcwebdesign.com
VM4 AusPost Shipping Plugin - e-go Shipping Plugin - VM4 Postcode Shipping Plugin - Radius Shipping Plugin - VM4 NZ Post Shipping Plugin - AusPost Estimator
Samport Payment Plugin - EcomMerchant Payment Plugin - ccBill payment Plugin
VM2 Product Lock Extension - VM2 Preconfig Adresses Extension - TaxCloud USA Taxes Plugin - Virtuemart  Product Review Component
https://extensions.joomla.org/profile/profile/details/67210
Contact for any VirtueMart or Joomla development & customisation

midnas

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

Milbo

Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

alopmar

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