Printable View
Deactivating the module doesn't remove it! Now corrupt info is in the database or in the code - I would need to install it "fresh".
Trying to install renders an almost blank page - only text at top of page: "WARNING: An Error occurred, please refresh the page and try again"
I came from 1.5.0 with no problems there!
Are you referring to this user-contributed module for v1.3.8 from 2010? http://www.zen-cart.com/downloads.php?do=file&id=661
Or something else?
The user contributed module for 1.3.8Quote:
Originally Posted by DrByte
Looks like it's got some bugs.
To remove all the configuration settings for that module from the database, run this SQL command:
Code:DELETE from configuration where configuration_key LIKE 'MODULE\_PAYMENT\_MONEYBOOKERS\_%';
How does ZenCart recognize a new payment module - i.e. where should I put the "new" code?
Does the zip contain all code or does it fetch more info from somewhere?
Zen Cart does not download plugins/modules from anyplace on its own. You upload the files to your server yourself.
That was sort of understood - I just wondered where I should place the module in the structure so that ZenCart finds it!?Quote:
Originally Posted by DrByte
And might the module do some uploading!?
What about the bugs - can I do something?
The general structure/placement of payment modules is two fold, one directory for the operation (includes/modules/payment) and one directory for language (sorry, but I usually have to go find the specific language directory path for any of the language related aspects, but a similar path in the includes/languages directory.)Quote:
Originally Posted by kalastaja
It is not so much a "new" module discovery, but everytime you open modules->payment section, all of the files ending in .php are loaded from those two directories... When a module file is found, an equivalent language file is expected, if not found then usually. An error message is logged and the partial blank screen or warning is posted...
In a sense there are levels to the code. Dr. Bytesuggested how to remove the database information about the module, this causes the module to sort of perform the first level as I have chosen to call it here.. Identify if the plugin is installed, if not installed then continue processing the other payment modules for display/payment.. That is if the module follows the expected general rules for development which based on the above discussion it at least is written properly from that perspective. Otherwise the suggestion would have included file removal.
As any user, you could work to rewrite/remove the bugs that Dr. Byte identified, though that may be a duplication of effort, or maybe not. Communication certainly is important in that regards, but I might suggest being ready to make a donation to the ZC team for the rewrite that may be coming from them/someone involved with them.
Btw, a lot of the questions about how/where things come from/get done etc, would be answered by starting to look at the code itself and researching what is not yet understood... In this case, a good place to start looking I think is in admin/modules.php. Then follow the bouncing ball and the notes in the file(s). Also helps to cross reference the output source code (choosing to view source code when the web-page is open in the browser.)
I still go with some of the previous, great to dig in sometimes, but also need to know when to put on the brakes and move on or accept that not fully knowing or understanding something is okay especially based on the source. Errors may happen, but they tend to still happen securely. :) point being, use your time wisely/appropriately. You're running a business, be sure that what you do supports that.
Ok,
All moneybookers modules are present (status red) in admin, but when clicking "+install" for Moneybookers main module I end up with numerous
and aQuote:
[04-Jan-2015 21:04:46 Europe/Helsinki] PHP Warning: mysql_real_escape_string(): Access denied for user 'root'@'localhost' (using password: NO) in /home/fh2fuvvy/public_html/store/includes/modules/payment/moneybookers.php on line 203
[04-Jan-2015 21:04:46 Europe/Helsinki] PHP Warning: mysql_real_escape_string(): A link to the server could not be established in /home/fh2fuvvy/public_html/store/includes/modules/payment/moneybookers.php on line 203
Will check into that. The configuration-table contains no entries for Moneybookers.Quote:
[04-Jan-2015 21:04:46 Europe/Helsinki] PHP Fatal error: 1062:Duplicate entry '' for key 'unq_config_key_zen' :: INSERT INTO configuration(configuration_title, configuration_key, configuration_value, configuration_group_id, date_added, configuration_description, sort_order, set_function) VALUES('', '', '', 6, now(), '', 0, '') ==> (as called by) /home/fh2fuvvy/public_html/store/includes/modules/payment/moneybookers.php on line 216 <== in /home/fh2fuvvy/public_html/store/includes/classes/db/mysql/query_factory.php on line 155
If Dr.Byte like to share his findings, I might be able to do something? (though I'm only a "Zen Follower")Quote:
Originally Posted by mc12345678
Your Zen Cart site has a bunch of folders at the top level:Quote:
Originally Posted by kalastaja
/admin/
/admin/includes
/includes/
/includes/languages/
/includes/modules
etc
So does a payment module (and basically every plugin). Typically when you unzip the plugin all the files are ALREADY located in the correct subdirectories, and your job is to upload those files to the same matching destination subdirectory on your server.
Do you know of a more intuitive way to do that without redundantly typing out "copy /includes/modules/languages/english/modules/payment/abc.php to your server's /includes/modules/languages/english/modules/payment/abc.php" ... into a readme for every file in the zip?
looks like that's another set of bugs in those modules. Whoever wrote those modules didn't use Zen Cart database access methods. Instead they wrote their own, and since Zen Cart 1.5.2-and-newer use mysqli_ instead of mysql_ because PHP has obsoleted the old mysql_ functions, that module won't work on the new version without rewriting all the database query calls.Quote:
Originally Posted by kalastaja
ANd it's not as simple as simply renaming all mysql_ functions to mysqli_ because PHP changed the parameter structure when they created mysqli_ functions.
Someone will need to rewrite those database query calls in the module's files in order to make it work. I can't do it today because I'm still in-transit on my way home from family vacation time. I also don't have a moneybookers account to use for testing anything, so I'd only be guessing about its functionality.
Ok,
Uploading is how I did my customization - four folders (to 1.5.4): installNew, installChanged (added my code to affected 1.5.4 files), adminNew, adminChanged (added my code to affected 1.5.4 admin files).
Thanks for your efforts - it's currently a bit out of my league! I could (try to) arrange for a moneybookers merchant account for testing purposes!?Quote:
Whoever wrote those modules didn't use Zen Cart database access methods....
Someone will need to rewrite those (polish?) database query calls....
BTW: The process don't seem that secure!?
Agreed ... I've always thought the Moneybookers "approach" was sketchy, and I know that if I was shopping from a site that only offered Moneybookers (assuming I could tell that's what it was), I'd probably go shop elsewhere.Quote:
Originally Posted by kalastaja
I did some investigating, and I'm pretty sure that you can edit the 2 files in that module which call mysql_real_escape_string and tell it to use $db->prepare_input insteadQuote:
Originally Posted by DrBytelooks like that's another set of bugs in those modules. Whoever wrote those modules didn't use Zen Cart database access methods. Instead they wrote their own, and since Zen Cart 1.5.2-and-newer use mysqli_ instead of mysql_ because PHP has obsoleted the old mysql_ functions, that module won't work on the new version without rewriting all the database query calls.Quote:
Originally Posted by kalastaja
ANd it's not as simple as simply renaming all mysql_ functions to mysqli_ because PHP changed the parameter structure when they created mysqli_ functions.
Files:
/includes/modules/payment/moneybookers.php
/includes/modules/payment/moneybookers/moneybookers_payment.php
Change 6 instances in each file:
mysql_real_escape_string(
becomes
$db->prepare_input(
Thanks. I will try it out!
Is it possible that someone in the community would make a better functioning payment module? How would one go about?
Generally speaking, development follows a lot of reading/research or whatever it takes to understand the required process flow of the payment processor. This is usually initiated out of someone's need for or interest in having such functionality whether personal or professional.
You are (of course) absolutely right.
My main concern is the robustness of the solution - the current is below bar. The gateway interface is documented, but would there be anybody who could share knowledge of secure payment? I do have some programming skills, but this might be a little too much, to run as a solo!?
BTW: Dr.Bytes changes worked!
Skrill/Moneybookers "support":
and I've got to work somehow - only main module though, not eWallet etc.Quote:
Skrill-Moneybookers 3.1.5 für Zen-Cart 1.5 deutsch
The discussion "continues" at