General developer forum

what am i wanting in a open source e-commerce plugin/s?

after looking at various software in research i have done up to this point...

i am wanting a "multi store, multi vendor, multi website" like functionalty built directly into moodle.  other words, many of the e-commerce / shopping cart software out there. including moodle. someone comes along and creates a mod (modification) / plugin for the software, so you could have www.mymy.com, www.meeme.com, www.moomo.com all point to a single moodle installation, and each of them having there own unquie setup and courses. 

with moodle. it gets a little bit more complicated, from SOHO (small office home office) setting, to K-12, to collage, to universities, to other. a one integration fits all, does not really work. with that i am looking to allow for....

(front end) of store what folks see going to some website, www.walmart.com, www.newegg.com, etc...

• www.moodle.org => my home page => add block (store front end).   = every person with a user account within moodle can have there own private generic e-commerce store, 
• www.moodle.org => course (course is the front end) = every course can have it's own private generic e-commerce store,  
  
• www.moodle.org => course => activity and/or resource (resource or activity is the front end of the store)= a private generic e-commerce store. 
• www.moodle.org ((front page / home page for site)) (unsure possibly a meta course) = it's own private generic ecommerce store.

admin side of things....

• www.moodle.org => my home page => add block (store admin)
• www.moodle.org => course => course adminstration block => store admin
• www.moodle.org => course => TURN ON EDITING => activity and/or resource => edit settings.
• www.moodle.org => ((front page / home page)) => site admin => front page => store admin.

using standard generic moodle database to allow above.

• new table named (mstore) with following fields
• id
• type (home page = 0, course = 1, activity = 2, resource = 3, user = 4)
• unquie id that moodle assigns for ((home page, course, activity, resource, user)

with above 1 table and 3 fields. a single database set (what ever is ported over) should allow for full range of independent stores throughout moodle.  each store being a complete fully functional e-commerce store, with front end and back end capabilities (within reason), using a single database set. no independent database for each store.

============

splitting up the front end and admin settings....

i am looking at "admin settings" as one time type of setting, localization settings, such as language, tax info, store name, store address/location, store description, contact info,. some of this info can be pulled from moodle already. along with orders, returns, various reports.

i am then looking at for the front end..."product" add/edit/delete.  for moodle a product = a activity type or a resource type, (special type = course itself). i am wanting to use the "edit settings" for each activity and resource of were a person would enter all the product info. (length, width,depth, price, sku, tags, product attributes, etc...)... other words goto any e-commerce / shopping cart admin section, to add/edit/delete a product. that entire section (normally multi tabbed) and dropped into the "edit settings" of each and every resource and activity type, as a "general module" for all of them. 

for more information see thread...adding conditions, and title changes to all activities / resources?

chicken scratch note taking...

• moodle -> lib -> classes -> plugin_manger.php = very bottom of file. notations for "standard plugins"
  
• moodle -> lib -> classes -> plugin_manger.php = public static function resolve_plugininfo_class($type)  = note on...
  • $dir/adminlib.php
    • moodle/lib/
    • moodle/mod/assign
    • moodle/lib/editor/atto
    • moodle/lib/editor/tinymce
    • moodle/enrol/flatefile
  • \core\plugininfo\general
    • i assume refrence is to moodle -> lib -> classes -> plugininfo
  • public function get_plugin_info($component) = frankenstyle compenet name
  • public function can_uninstall_plugin($component) = check depends looks like something needs to be set in say per each payment gateways, so paymentgateway manger can not be uninstalled. 
    • protected function common_uninstall_check(\core\plugininfo\base $pluginfo) {
    •         if (!$pluginfo->is_uninstall_allowed()) {
    •             // The plugin's plugininfo class declares it should not be uninstalled.
    •             return false;
    •         }

• moodle => lang => en = core lang files.
• https://docs.moodle.org/dev/XMLDB_editor
  
  • create moodle/mod/mymodule/db
  • make sure db folder has write access *doh*
  • then goto site admin menu => developers => xmldb
  • create should be clickable 
• https://docs.moodle.org/dev/Roles
  

=================

• need to figure out why... http://localhost/moodle/admin/tool/xmldb/  does not auto create all the database tables. or if it does it on demand. and if i need to do something for plugins to allow for it. 
  
• need to read up on "foreign keys"
• want to check to see if 2 databases can be ran side by side, 1 for basic moodle. 2nd database (different username/password/host/etc..) used stuff that holds the money.  or to simply. off load an overwork database server and spread the database tables out to different physical servers. not looking forward to diving into it.
• need to find some default numbers of what different values are set at. such as ID fields. so someone is not running out of database ID numbers due to field was set to small. or if there is a "default" value some place i can set field sizes to. 

===========

• https://docs.moodle.org/dev/Local_plugins = talk about local plugins very last things to load. and possibly over riding different aspects of core functions / code. but not much detail on that.
• lost link in tracker = something about common plugin and getting away from $module all together or something like that.
• moodle -> lib -> form = all the various form types

chicken scratch notes of mine. 

=================================================

interesting... looks like there is an "auto update" for moodle. and if you get your plugin listed within.... www.moodle.org/plugins  your plugin will get tagged by "auto update" if there is an updated version available on www.moodle.org/plugins  by the auto update.  this is assuming you have enabled "auto update" in your moodle installation itself. 

it would seem to check the "version.php" of the plugin. and the version number within it. against a database table entry that happens during install of the plugin, vs version info at www.moodle.org/plugins  ((not a clue how, yet, that is.))

i am guessing above maturity level. is dealing with development process, setting up a tracker, etc... to point "your given plugin" is listed on www.moogle.org/plugins

=================================================

• moodle => lib => classes => compenent.php (lines 333 through 446)  
  

it looks like core plugins, are getting a cheat sheet per say, with the above, to increase overall server performance, vs reading in each independent plugin type on each page load. 

there is a duplication of both arrays some place else ""other file""  (in a link in one of the recent previous posts if memory serves me). i need to figure out what is the "new way" vs dealing with the "old way" the arrays look the same, but the written out code is completely different, and steps through each sub folder. via a foreach maybe? or a single subfolder maybe that is what it was, a limit of one subfolder depth? exception for tinymce and one or two other notations.

• admin/localplugins.php
• admin/settings/...( all ).php
• course/render.php 
  • create a html wrapper for products and most likely edit a couple of the functions there, to deal with how links are created. along with inserting "buy now cash amount
• course and sections.
  
  • course/lib.php
  • course/edit.php
  • course/edit_form.php
• mod = activity / resource
  • course/modedit.php
  • course/modedit.php
  • course/modlib.php
  • course/moodleform_mod.php
• lib/adminlib.php
• lib/modinfolib.php
• lib/moodlelib.php
• lib/classes/plugin_manager.php
• lib/classes/plugininfo/
• lib/classes/plugininfo/... ( all ).php
• lib/form/...( all ).php
  
• had some a couple javascript files tagged. but done forgot them.

do not remember were but there were 3 different arrays, of "core plugins", one array seemed to be the "old way and getting eliminated", and the other 2 arrays, were "new way" but unsure...  they were like cheat sheets to deal with better performance on core plugins.

=====================

need a way to handle multi type of plugins....

• store = moodle/store/
  • this also holds data for inserting menus and handling plugin manager for these plugins in site admin
  • also holds data for displaying "forms" for "store settings" (see further below)
• store = moodle/store/plugins
  
  • basic stuff, already there, but meant to extend beyond original coding with plugins. so say instead of selecting a product category, you could also select a google product category, or a ebay product category. these would be plugins. granted not best examples. for a store, it might some sort of push/pull product feeds or something from a manufacture / publishing house or like.
• store = site admin => plugins => store 
  • for above plugins 
• store = database table 
  
  • for generic settings ((need to re-look how moodle handles settings of this nature))
    
• store settings = site admin => front page => store settings
  • default site store (were one would enter, settings for above plugins)
• store settings = course admin => store settings
  • possibility of treating each course as a separate store

==============

• paymentgateway = moodle/paymentgateway/
  • this also holds data for inserting menus and handling plugin manager for these plugins in site admin
  • also holds data for displaying "forms" for "paymentgateway settings" (see further below)
• paymentgateway = moodle/paymentgateway/plugins
  
  • for expanding payment gateways, such as paypal, autherize.net, etc...
    
• paymentgateway = site admin => plugins => paymentgateway
  • for above plugins 
  • this needs to do extra duty. so plugins can be "reused" but different settings. (paypal with say john doe), another store front might want to use (paypal with alex uoa), another may want to use (autherize.net someone else, and different settings)
• paymentgateway = database table 
  
  • for generic settings ((need to re-look how moodle handles settings of this nature))
    
• paymentgateway settings = site admin => front page => store settings => payment gateway
  • default site store (were one would enter, settings for above plugins)
• paymentgateway settings = course admin => store settings => payment gateway
  • possibility of treating each course as a separate store and needing there own payment gateway setup.

==============

commercial address = comaddress / com_address

• comaddress = moodle/comaddress/
  • this also holds data for inserting menus and handling plugin manager for these plugins in site admin
  • also holds data for displaying "forms" for "comaddress settings" (see further below)
• comaddress = moodle/comaddress /plugins
  
  • for expanding database table by adding additional fields ((most likely will come in handy for accounting))
    
• comaddress = site admin => users => comaddress 
  • for above plugins 
  • i need to tag multi types of addresses (billing, shipping, manufacture, user, etc...) and multi of them per person. this also goes with, credit card companies / shipping companies, that may return a "legit address" vs sending back "address = fake" or like, when you do handshakes with these companies via computer code, to get shipping quotes or to getting your money via credit card, to returning money, the can send back different responses in a way to prevent lost money.
• comaddress = database table 
  
  • for generic settings ((need to re-look how moodle handles settings of this nature))
    
• comaddress  settings = site admin => users => comaddress settings
  • were to find plugin settings 
• comaddress settings = site admin => users => comaddress
  • add/edit/delete = comaddress for users/manufactures/etc.. manually. vs them entering it.

===================

below need a 

• simple database table
• simple form (exception tax rates)
• site admin => plugins => commerce => listing of each one below
• moodle/localisation/listing_of_each_one_below.php  
  • no plugins beyond (localisation) being treated as a single plugin, just straight name.php, name_form.php for all of below.
  • localisation acting as a plugin, would handle inserting of menu names. and a single version number for all of below.

all of the below notations are found under... opencart/admin/ (menu on let) => system = >localisation

• currencies
  
• stock status
  
• order statuses
  
• return statuses
  
• return actions
  
• return resasons
  
• zones
  
• geo zones
  
• tax classes
  
• tax rates  ((little bit more complicated))
  
• length classes
  
• weight classes
  

i do not believe above would be edited / changed a big amount. beyond initial setup of server or when laws come into effect and need an update.

====================

brain fried, ending here. before i wait and come back and loose it all again.

2nd time around. the "save draft" of the editor has nailed me a couple times now... in middle of a CTRL Z and/or CTRL Y (undo / redo) and it zaps post away. not about to re-type it all backup.

============

comaddress = renamed to "addressbook"  sounds a bit more understood of what it is.  i did look some what at "users" and adding mod for users. but unsure (did not go into depth). the need to create multi addresses and link to a single user is what is wanted. and not sure if that is possible easily with what currently in moodle.    

billing address, shipping address, different credit card addresses, different ship to addresses, "address checking" from shipping and payment gateways. manufacture descriptions and assigning to products, etc...  info coming in from plugins, and be able to update there "address book info" info coming in from facebook or like. 

=============

getting a tad lost in creating a plugin,   primarily with all the little "what can and can not be included" in the verison.php, settings.php, db/access.php, db/install.xml

also getting lost, in creating the functionality of plugin types. local, mod, admin/tools, cache, enrol, auth, etc...  were you have a "plugin manager" under site admin menu => plugins => plugin manger, then a listing under that if any plugins that require additional settings. everything is already "core plugin" that allows the x_folder = special type of plugin. other words i have not come across a www.moodle.org/plugin that does same thing. as what the core moodle plugin types allow. the nearest i have came across is a couple that use the "dependency" settings in the "settings.php"

================

have destroyed moodle installation a couple times already (files and database tables). primarily with "XMLDB editor" and getting a bad "install.xml" other times commenting stuff out were i should have not been putting in // or using wrong variables for string names. *woops*, a couple times some how causing plugin to be installed a few different times and getting multi listings on the config_plugins database table for the same plugin. i have lost and gained a few site admin menu items a few times as well *woops*

i have had to "disable caches"  "under site admin menu" there be a "search box" type in "cache" and brings up results to disable a few cache' (themes, javascript, html, php)  this has helped a lot with issues above. the default "wamp" appache, mysql, php were all put onto a single cpu core. vs going into the multi core cpu.  and just maxing out the one cpu core.  after disabling the caches, the wamp/moodle started to run much faster on this dev computer.

i had at one time enabled "site admin menu => developer => show error messages" and the other settings. and that also seemed to cause some extra issues.  turning them all off and setting them back to normal, and issues above, began to clear up. 

with above said. keep with the default install of moodle when developing! seems to work best so far for me.

================

off to edit core files this time vs creating a plugin. to see if i can better duplicate a few things. 

went with moodle 2.9dev version with latest re-install. 

went through and did a "find in files" for "auth" and "enroll" in attempt to ID key files / folders. and then copy / pasted into another folder. to make it quicker to search them. ((see attached test.zip))

moodle/lib/editor/tinymce  might be a easier "something" to copy info for sub-plugins. now that i am looking more at it. less involved vs other core plugins.

=====================

• orphaned, and deprecated notations both in code, and files named. has me some what concerned.
  
• much confusing, of what runs first and what runs last. as far as code execution. ""refering to code comments inside the code / files"" more to do with "local" folder, core plugins, and then third party plugins. which order?
• it almost seems like a "copy paste" happened.  between original plugins, and then making them core plugins. and just copying functions / classes into specific files. 
  • other words there is enough repeat of different type of settings and use of functions in same single file, to choose and pick from, vs searching all over the place. or at least that is the hope!
• i did find the local folder more to... "customized installs" vs anything else via "default.php" and just setting some settings, and changing string names possibly. 

=======================

off to edit core files again, and see what happens, hopefully will not destroy another moodle installation, from own chicken scratch attempts. 

more chicken scratch notes

2 steps forward 3 steps back! i thought i was nearing point of being able to copy/paste of moodle/enrol to moodle/paygate" and then copy/paste to moodle/ordertotals, and moodle/productinfo, etc... but keep hitting extra snags. primarily due to enrollments are tied into everything within moodle.

•  site admin menu -> plugins -> plugins overview 
  
  • scroll all the way down,  and see "paygates"  need to find string for this again to reference to "payment gateways"
  • flat file fake1 and flat file fake2 (copies) plugins showing up correctly, with version info
  • ========need to run cron, and flush caches======== for this area to show up. ((due to manual edits of files and not updating version number))
•  site admin menu -> plugins -> payment gateways -> manage payment gateways
  
  • copy of site admin menu -> plugins -> enrolments -> manage enrolments
  • links working = name, enable/disable, up/down/ settings, and uninstall
  • not working = instances / paymentgatways = not enough yet to change code.
  • not working = foreach statements to show individual settings of enabled plugins, and listing them below the table, like page for "manage enrolments" does.
•  site admin menu -> plugins -> payment gateways -> flat file (fake 1) plugin
  
  • copy of site admin menu -> plugins -> enrolments -> flat file
  • changes made are being saved, not actual uploading a file, but check boxes seem to be working.
•  site admin menu -> plugins -> payment gateways -> flat file (fake 2) plugin
  
  • copy of site admin menu -> plugins -> enrolments -> flat file
  • same as above

=====================

issues to above

• have yet to figure out how to change the admin menu -> plugins -> enrolments -> manage enrolments -> (top table)  of what is and is not displayed, for copy i did for payment gateways. 
• just now noticed in typing this up, that the "for each plugin" is not work as well on the "manage payment gateways" in showing there settings below the table.

=====================

logging in as admin going to a course.....

• course administration -> users -> enrolled users
  
  • http://localhost/moodle/enrol/users.php?id=2 
    • works
  • http://localhost/moodle/paygate/users.php?id=2 
    • sorry, but you do not currently have permissions to do that (review course payment gateways)
    • not showing up in in the menu, and directly changing URL to get above.
• course administration -> users -> enrolment methods
  
  • http://localhost/moodle20141224_a/enrol/instances.php?id=2 
    • works
  • http://localhost/moodle20141224_a/paygate/instances.php?id=2 
    • sorry, but you do not currently have permissions to do that (review course payment gateways)
    • not showing up in in the menu, and directly changing URL to get above.
• course administration -> users -> other users
  • http://localhost/moodle20141224_a/enrol/otherusers.php?id=2
    • i think i goofed up, does not show test student, 
  • http://localhost/moodle20141224_a/paygate/otherusers.php?id=2
    • shows test student, that can be assigned a role. (nothing works to assign)

=================

issues to above

• i think i am missing some sort of capabilities, some place
• along with enrolments / paygate copy conflicting with each other in the course administration -> users (user menu item itself) 
  • the code creating "users" menu the code for it, (going from memory here), is not easily copy/pasted if memory serves.
• moodle/paygate/test_settings.php and moodle/paygate/locallib.php ((copies from)) moodle/enrol/test_settings.php and moodle/enrol/locallib.php take care of "site admin menu"
• but all the other files
  • externallib.php
  • ajax.php
  • bluchange.php
  • bulkchange_forms.php
  • editpaygatement.php ((arghs)) one error there *changes it to* editpaymentgateway.php
  • editpaygatement_form.php ((arghs)) one error there *changes it to* editpaymentgateway_form.php
  • index.php
  • otherusers.php
  • renderer.php
  • unpaygateusers.php
  • users.php
  • users_forms.php
• all above files are pulled from other locations... primarily from course administration -> users -> (menu options) and having issues with. i would like to think it is just capabilities. but also some menu navigation issues as well i do believe.

===========================

===========================

• how many different ways can you spell enrol?
  
  • enrolment, enrollment, enrolments, enrollments, enrol, enroll, enrolled, ENROL, Enrol, and a couple other varitions of enrollxxxx that did not have "ment" after it.
  • the enrolments and enrollments ((double LL's)) has me!
• find in files, replace with...(matching case) then (without matching case)
  
  • enrolment = paymentgateway
  • enrollment = paymentgateway
  • ENROL = PAYGATE
  • enrol = paygate
• i do not think i have ran into any "enrollment" (double LL's) in code. and are all in comment tags // /* */ but i may very well have mis-read and applied the wrong "replace"

==========================

==========================

following files edited to get basic "site admin menu -> xxxx" working (see top of this post) they are either direct copies of "enrol" replaced with paygate within folder/file name. or copy/paste of code / function of enrol in the files.

• moodle/admin/paygate.php
  
• moodle/admin/settings/plugins.php
  
• moodle/lang/en/paygate.php
• moodle/lib/adminlib.php
  
• moodle/lib/paygatelib.php
  
• moodle/lib/setup.php
  
• moodle/lib/classes/componenet.php
  
• moodle/lib/classes/plugin_manager.php
  
• moodle/lib/classes/plugininfo/paygate.php
  
• moodle/paygate/loocallib.php
  
• moodle/paygate/test_settings.php
  

flatfile plugin for enrol, copied over to paygate. pretty much straight forward "find in files" and replace enrol with paygate in code, and edit a couple file/folder names as well to reflect paygate vs enrol

currently cheating... using phpmyadmin with mysql database. to export "enrol" table, edit table names and fields for paygate, and then importing back into moodle database. along with entering a couple entries directly into tables "config" and "config_plugins" ((copy/paste of enrol to paygate notations in the tables))

=========================

i keep forgetting about...

• moodle/lib/db/access.php
  
• moodle/lib/db/install.xml ((skipping for moment))
  

=========================

see if i have things covered 

https://docs.moodle.org/dev/Local_plugins

• /local/xxx/db/install.xml - executed during install (new version.php found)
• ((not yet dealing with)) /local/xxx/db/install.php - executed right after install.xml
• ((not yet dealing with)) /local/xxx/db/uninstall.php - executed during uninstallation
• ((not yet dealing with)) /local/xxx/db/upgrade.php - executed after version.php change
• /local/xxx/db/access.php - definition of capabilities
• ((not yet dealing with)) /local/xxx/db/events.php - event handlers and subscripts 
• ((not yet dealing with)) /local/xxx/db/messages.php - messaging registration
• ((not yet dealing with)) /local/xxx/db/external.php - web services and external functions descriptions
• ((not yet dealing with)) /local/xxx/cron.php - cron job, run at the interval defined in version.php. Alternatively, you can define local_xxx_cron() in lib.php. (The lib.php method is now preferred.)
• /local/xxx/lang/en/local_pluginname.php - language file
• /local/xxx/lib.php - function library, automatically included with by config.php. Hook functions local_pluginname_extends_navigation() and local_pluginname_extends_settings_navigation() can be used to add items to the navigation and settings blocks
• /local/xxx/settings.php - configuration options. These get added to the admin menu.

================

• https://docs.moodle.org/dev/NEWMODULE_Documentation
  
  • need to take closer look at...
• https://github.com/moodlehq/moodle-mod_newmodule ((COOL! wish i found it sooner))
  
• https://docs.moodle.org/dev/Plugin_documentation
  
• https://docs.moodle.org/dev/Subplugins
  
• https://docs.moodle.org/dev/Automatic_class_loading
  

=================

need to look more in depth in the "availability API", and "completion API". to see about dealing with actual, person has paid for item/course/module. vs has not paid for item/course/module. 

purging all caches, and running cron.php was not updating certain things in database... guess it is, done at initial install of moodle. and never rechecked there after, exception during actual install/uninstall of a plugin.

• database -> mdl_capabilties -> moodle/course:enrolreview, copying line change for paygate
  
• database -> mdl_capabilties -> moodle/course:enrolconfig, copying line change for paygate

assigned initial admin account i been using as a manager role, and included above cap's into manager role. 

nearly there with course admin menhu, just not sowing paygate stuff with enrol stuff in the menu. 

looks like i need todo some copying of

• database -> mdl_external_functions

===================

needed a break, from moodle. and been looking at opencart...

opencart has files all over the place (different sub folders), and getting tired of clicking back and forth. so been using www.advancedrenamer.com to add in folder paths directly into file names. and then cut/pasting files into quickly made up moodle plugins.  

also trying to get some common ground, of payment gateway functions. creating spreed sheet. to and tagging down the functions in it. 

((above is what attached files are about moodle/paygate/, moodle/shipping/, moodle/ordertotal/))

====================

been trying to figure out were to place "checkout pages" do i include them in paygate folder as extra files. or do i go with moodle/checkout/  like moodle/enrol/.  i suppose "checkout" being seen in browser url, might be something. 

shopping cart,  (edit amount, remove items, select shipping possibly) kinda of "checkout" but also shopping cart page. there is a distinctive split, but not really noticed. (to use to ordering stuff online to notice anymore),  of course a block for a shopping cart. moodle/block/shoppingcart,  but also "user menu", and "navigation menu" would be using same code. thinking about it, i guess it does not matter. as long as i can add a menu item from a moodle/block(code itself) and get it to the "theme" *not a clue how theme's work yet* 

========================

tossing in opencart license.txt to attached files, seeing they do not include info directly in any of the files i have looked at.

it is slow :/ as in CPU INTENSIVE slow... 

==============================

moving all of opencart database tables over to moodle. and then outputting xml from the xmdldb editor.

==============================

STEP A:

CHEATING: using windows 8.1, with wamp2.x (comes with apache, php, mysql, and phpmyadmin). 

1. install opencart like you were going to actually use it. so it creates all the database tables, and is ready to start putting in product details, etc....
2. goto www.mysite.org/phpmyadmin
3. export all of opencart tables, in sql, or like format.
4. open up file from above, and do a search and replace for "oc_" to "mdl_local_oc_"  and select replace all
   1. oc = prefix used in install of opencart
   2. mdl = prefix in moodle database tables
5. import the edited opencart file into the moodle database tables

==============================

STEP B:

NOTE:  "oc" in step's 1, 3, 5.5, and 6 below ="oc" prefix of above...

1. create folder "oc" under www.mysite.org/moodle/local/oc
   
2. create folder "db" under www.mysite.org/moodle/local/oc/db
   
3. place version.php in www.mysite.org/moodle/local/oc/version.php with the following info...
   1. defined('MOODLE_INTERNAL') || die();
   2. $plugin->version   = 2010101000;               // The current module version (Date: YYYYMMDDXX).
   3. $plugin->requires  = 2010031900;      // Requires this Moodle version.
   4. $plugin->cron      = 0;               // Period for cron to check this module (secs).
   5. $plugin->component = 'local_oc'; // To check on upgrade, that module sits in correct place.
4. login to moodle as an admin
5. goto site admin menu -> notifications
6. let moodle install "local_oc"
7. goto site admin menu -> developers -> xmldb editor
8. scroll down and you should see a listing for "local/oc/db"

NOTE: the "db" folder and version.php file are minimum required to get a listing to show up under... site admin menu -> developers -> XMLDB editor.  

==============================

STEP C:

this is were things begin getting problematic and slow... *feels like he is back on dial-up connection*

1. click [create]
2. click [load]
3. click [edit]
   1. DEFAULT, a table... local_oc is created.
   2. we can edit the local_oc table if wanted (ready set go for basic simple plugin)
4. [View original] [View edited] [New table][New table from MySQL][View SQL code][View PHP code][Back to main]
   
   1. we are intrested in [new table from mysql] so click that.
5. from the drop down menu, you can select, database tables already in the moodle database it would seem.
   1. selecting, "local_oc_attribute"
6. the after table... i have not figured out yet, i assume it is there, so code shows up in a certain order in the.... www.mysite.org/moodle/local/oc/db/install.xml  file
7. click "create"

==============================

STEP D:

this is were things become problematic... moodle XMLDB editor, hates it if there is no "KEY",   oh it will let you save it it, and add new fields, etc... but if you leave this page with out creating a "KEY",  you are in trouble... if you do leave this page then....

• goto ftp program, or in my case windows/file explorer, and delete www.mysite.org/moodle/local/oc/db/install.xml,  you could also rename install.xml to something else as well.
  

or

• manually edit www.mysite.org/moodle/local/oc/db/install.xml file. and add in the XML for the "KEY" for the given table

1. write down the name for the "primary / unquie / ID column for this table" in this case it is...
   1. attribute_id
2. [View original] [View edited][New field][New key][New index]
   
   1. click [new key]
3. NAME: = PRIMARY
   1. READ, name = PRIMARY, for initial first unquie id, from what i have figured out so far. if you put name as anything else, you will get problems. and errors, when you go to save your work, or go back and edit things
   2. and it needs to be in CAPS, and not in lower case it would seem.
4. COMMENT: = empty or anything you like
5. TYPE: = PRIMARY
6. FIELDS: = attribute_id
   1. from step 1.1.  above,
   2. column/field name that is unique/primary,   most initial field names in database tables are named ID, 
   3. click "change"

===================================

STEP E:

1. at this point... you should be safe, and able to to click [save]
   
   1. [View SQL code][View PHP code][Save][Back]
2. click [back]
   
   1. [View SQL code][View PHP code][Back]
3. click [back to main]
   1. [View original] [View edited] [New table][New table from MySQL][View SQL code][View PHP code][Back to main]
4. click [unload]

5. local/oc/db

   [Create]

   [Load]

   [Edit]

   [Save]

   [Doc]

   [XML]

   [Revert]

   [Unload]

   [Delete]

i am not sure what the "load" and "unload" stuff is all about. and why you need to load stuff up, before you can edit stuff. but *shrugs* playing it safe. for now...

random thoughts, as i await for XMLDB editor pages to load/finish

foreign key, soft delete, hard delete, keeping records of someone paying for something. and not have a course delete / restore / backup, or an activity or resource, or block. go back and destroy / hard delete the info for buying this or that.

were is a line drawn. so finical data is protected... reading up on various ways to handle "soft delete"

for performance, having a second set of database tables is suggested from what i been reading. it keeps the main database smaller. and would let the second database / second tables. get bloated. not really matter. (within reason), the issue was getting data back from, second database tables, and put back into primary. and the extra complex sql strings that would be needed. 

is there a way to edit, the database layer / abstraction layer. ((xmldb))  so that entire moodle, and/or basic plugin types, worked. without need to edit each and every plugin. 

----say if sql string noted an update in it, then... change "update" to "insert" and change database names to "soft delete tables", then run the string on main database tables.

---say if sql string noted a "delete" in it, then... change delete to, insert and change database names to "soft delete tables", then run the string on main database tables, to delete the given row or rows. 

guessing retrieval "going to recycling bin" and choosing undelete. would be a nightmare to code, but just enough for admin's to be able to go back and retrieve data. or to generate reports from. 

i realize "events" are short cut of above per say and only giving min info, and most likely gives good logging, and high performance, but hhmmsss...

============

other issue, is "order history" going to any given company website, ya purchased from, and going to your orderhistory, and pulling up date of what you purchased. some give very min amount of info, "plain title and cost per item", others give a bit more. i would like to see more. but most likely out of scope of this initial start of this project. 

will each module (resource / activity) need something basic from it?  such as a title and pulling a description from it? guessing most modules have there own dedicated table they store this info in. to pull "order history" xxxx title bought... xxx description of it.

====================

looks like country / state info for time zones to geo_ip, to other. are in txt files. or in a php file vs in a database table in moodle vs opencart and info is in a database table, hhhmssss.... taxes :/ and tax zones...

i suppose a file might be better for security vs database. being able to turn off write access to the file. one less database query, and taxes not calculated a whole lot, exception during checkout. meh... see what happens when it comes time to redo functions and sql statements. if a hacker gained access to db, they have it all anyways. most likely easier to connect to third party software if info was in a database. vs having to make a second function just to call up a file and do a cross reference. 

not finding much of "pre loading" anything in moodle database tables. now that i search for "insert" across all files of moodle. hhhmsss.... why is that? database = stuff that changes, and info that is static, is static long enough it does not matter? and just include it in a version upgrade? so say a file compare utility or diff, will show changes. vs rummaging over database tables trying to find the difference?

=============================

=============================

=============================

=============================

ok.... 

• opencart2.sql 
  
  • phpmyadmin export / sql dump of opencart database
  • and then search/replace oc_ to mdl_local_oc_
  • then imported into moodle database
• install.xml
  
  • see previous 2 posts. this is result before changing anything...
• moodle initial install.xml 
  
  • for reference
• lisence.txt
  
  • opencart lisense.txt not sure of sql dump counts or not, but making sure.
• install.xml.xmldb_editor_errors.txt
  
  • site admin menu -> developer -> xmldb editor -> local/oc/db -> [load]
  • these are errors i get, that prevent me from clicking on [edit], and fixing the errors directly through xmldb editor. 
  • looks like i have "to long of names" 30 cc limit? i assume cc = character limit?
  • looks like i have some CAPS / camel casing of tables and field names, everything needing to be lower case.
  • looks like i need to check "reserved words" i don't see and error of such from skimming the errors.

been kicking the can around, trying to figure out how to handle "payment gateways" more to the point... PCI DSS compliant.

if you do not store any credit card info, much easier to pass PCI DSS, as soon as you store or any info is obtained on your servers. then PCI DSS compliance goes up rather fast, in how much extra security you need in place.  security not via moodle / commerce thing. but rather physical access to the server, and keeping records, and more to it, keeping things up to date "security wise" hardware, operating system, apache, php, moodle, commerce, etc... 

looking over different payment gateways...

• some use an IFRAME, 
  
• some completely direct customer off your website and onto their website. 
  
• some allow you to take info on your website, but never actually stores any info. (cache is disabled)
  
• some allow you to store min amount of info, perhaps last 4 digits of credit card number, issueing bank number, billing / shipping address.  (no info for ccv / security number on back of card, or start/expire date, or full credit card number.)
  
• some allow full info of credit card to be saved. (within limits of rules / regulations / laws)
  

======================

re-occurring billing is also an issue.   kinda like gas company, eletrical company, phone company, etc... you get your monthly bill.  these would be re-occuring bills per say.  but going a step further "re-occuring payment",  more likely club fee, or magazine fee, netflix fee, website fee, web server fee.

• some payment gateways. do not even offer this. 
  
• some payment gateways hold all the credit card info on there servers. ((easier PCI / DSS compliant)) 
  
• some if you hold data on your own servers. you can auto bill directly through your own server through some payment gateways.
  

======================

PCI DSS compliance with hardware. (credit card scanners) is a bit different.  and possibly a different "merchant account" can be had, vs using online internet payment gateways. but still same like rules apply about how much credit card info is stored on your own servers.

======================

====================

======================

with above i am trying to figure out a way. of how to describe the payment gateway, for PCI / DSS compliance. when you goto... site admin menu -> plugins -> manage payment gateways,  the table that shows up... (like if you went to filters, auth, enrol, etc...)  looking for some sort of CODE or number system, that i can drop into the table. and then give extra detail through a "help icon" or display info above / below the table. 

bit masks. might work. but i do not really want to flood moodle with a bunch of extra bit masks.  

yes "price" always come into things. of how much X will charge over X.  but thought i might drop in a "warning" sign.  so non tech folks, when they go in and look over payment gateways and choosing something... they see a warning... with thoughts of "HEY, if your non geek, and do not know how to keep things up to date and secure,  this type is bad idea, due to possibly some *evilhacker* hacking of your server, and folks credit card info being stolen, due to credit card info is stored on your server.  vs all credit card info being stored on the payment gateway servers. 

to above, yes a bitmask will most likely be created for "roles / Capabilties" warning of possibly finical info being edited/added/deleted. but above is more of a "warning" and trying to figure out KISS (keep it simply stupid), which may mean, nothing at all. but perhaps maybe a little more?

===========================

green, yellow, red icons?   (go, caution, stop) as in street lights (go, caution, stop) green = no info is saved on your servers, yellow = some info, red = as much info as possibly is saved on your servers. 

meh... gotting ahead of myself...back to the grind stone to getting basic commerce done. 

===========================

===========================

===========================

re-occurring billing / re-occurring payment.

have received a couple messages of folks asking about this... at moment, it is on the "want list" but most likely will wait till "accounting" back end comes around. 

there is a few payment gateways that due support re-occurring billing / payment. but i am most likely going to approach payment gateway plugins. like opencart, zencart, oscommerce, oscmax, etc... and let the plugins dictate how to handle that.  until... accounting back end is done. so that late fees, and like can be done, along with "user accounts" ya go in buy this big expensive course with books. and pay the debt off of the course of so many days/weeks, etc...  or simply sign a contract or paper, and then get a bill Y days later, and need to be paid X days.  this will most likely have bank transfers more coded in. along with re-occurring billing / payment more fully supported.

============================

with above said...  i am looking at... 

www.yoursite.com/moodle/checkout as being a plugin manager. to handle different types of checkout. pay before you get access/item is shipped, re-occurring billing, re-occurring payment, POS (point of sale) cash drawer, POS smartphone, user account, guest checkout, create account before purchasing, etc...

www.yoursite.com/moodle/ordertot = plugin manager to handle "receipt notations" vouchers, discounts, shipping costs, tax, sub total, overall total, group discount, etc....

www.yoursite.com/moodle/paygate = plugin manager for payment gateways (paypal, twocheckout, skrill, *brain going blank from all of them*)

www.yoursite.com/moodle/prodinfo = plugin manager for (stock levels, SKU numbers, tags, etc...)

www.yousite.com/moodle/shipping = plugin manager for usps, ups, dhl, fedex, freight, flat rate, etc... shipping plugins.

www.yoursite.com/moodle/storeinfo = plugin manager = different physical store locations / different shipping locations, were to pickup (class room 2A, other school front office, etc...) store name, address, contact info.

www.yoursite.com/moodle/block/cart = shopping cart block.  also doubles for inserting menu items into user menu, possibly navigation menu

www.yoursite.com/moodle/block/wishlist = wishlist block. 

..............

www.yoursite.com/moodle/garbage crud = stuff i been sorting around and still have not gotten to and/or will not port over to moodle.

............

i am unsure were to place, "orders / sales / returns",  they are reports, but they are not, due to add/edit/delete of orders/sales, (updating payment (say from check cleared, to has shipped, has tracking number,etc..), to dealing with return from single item out of entire bunch of stuff that was bought and like. along maybe needing manager approval before something is returned.

thinking about going with....

www.yoursite.com/moodle/pos/ = point of sale manager.  and for now...  www.yousite.com/moodle/pos/webpos to handle basic (orders, sales, returns),  and then latter doing pos/smartphone,  or pos/cashdrawer or like. 

---errr  www.yousite.com/moodle/checkout  handles most of that... is POS more of "employeed staff" screens? or rather front end for them? do i need to move... checkout from root folder, to pos/checkout folder. and treat web checking out, more as a selfweb (self website checkout), kinda like self checkout counters at various stores, checking out online, is just that self checkout in a sense, but stuff is shipped to you.

thinking about it more... creating a few functions. might prove better long run. going with the  www.yoursite.com/moodle/pos  and then dropping in returns.php, sales.php, orders.php and like files into the "pos" folder...or perhaps www.yoursite.com/moodle/pos/manager/returns.php, orders.php, etc..

hhmmmsss seems i am still confused. of what to do about this...

===============

returns, orders, sales... what about a course format for each one? or a module (resource / activity?)  for each type?  setup a course and only enrol X folks into it... upgrade role from student to teacher, for more functionality... rename roles if wanted form student to cashier,  teacher cashier/returns,  or some such...  setup groups if wanted. each person there own group... and a different cash drawer. or different location. a different activity for "out on businesses trip at some conference, and selling a few goods with cell phone or with laptop. 

===============

taking a break and coming back to it for checkout and/or pos.. still no good. i guess sleep on it for another night... and work on getting the other plugin managers going.  was hoping to see about getting a github going tommorw, but that may be held off.

MDL-48712 tracker for commerce... a commerce package for moodle.

https://github.com/boggen/commerce_for_moodle

adding github finally. simple copy/paste and search and replace, and search and rename has been done. no actual functions / classes coded. at moment just showing off the "plugin managers"  located in site admin menu -> plugins.  (they are not finished out, just roughing out location of plugin managers for commerce, "prep work").

==============

to see plugin managers, it requires a full fresh install of above. it will be assume that edit of core files of moodle will be need to happen before it is all over with

==============

next on TODO list. is roughing out area for 

• www.yoursite.com/moodle/enrol/commerce   
  
• www.yoursite.com/moodle/blocks/shoppingcart
  
• and adding some areas to current menus to add/edit/delete product details / store information. like you would be able to in a generic ecommerce software package.  there most likely need to rought out "product info" plugin manager and plugins for it. before something can advance enough in roughing things out.

print screens of roughing things out in moodle. with open cart counter part screen in admin. 

EDIT: moodle.org was reducing picture sizes to an un-readable size.  result. removed and placed images in zip files.

www.yourite.com/moodle/availability/condition/purchase

• not able to "copy/paste and then search/replace" it would seem, to create a place holder and still have functionality still there. something is happening within the javascript side. and causing a <textarea> to show up that is blank vs having buttons to add restrictions :/ 

going through the conditions that come with moodle along with....

• https://github.com/numbas/moodle-availability_username
  
• https://github.com/jleyva/moodle-availability_mobileapp
  
• https://github.com/jojoob/moodle-availability_geolocation
  
• https://github.com/ewallah/moodle-availability_condition_language
  
• https://github.com/ewallah/moodle-availability_coursecompleted
  
• https://moodle.org/plugins/view/availability_xp  requires https://moodle.org/plugins/browse.php?list=set&id=58
  

it would seem there is a bit more to the javascript / YUI  that is going on. resulting in the javascript to not to work. going to leave this hanging for now.  needing to get class/functions written, before getting to this any how.

====================

additional print screens in roughing things out within moodle. of were to add "product information, and store information" to sell categiories, courses, and activities / resources.  ((see above note about not displaying activities/resources better))

EDIT: moodle.org was reducing pictures to an un-readable size. result. removed pictures and placed them into zip files.

address book....

multi language errr multi country functionality.... every country is different in format of the address.  some countries / government bodies have different way of describing things, but in a different order.  some things are required in one country, but is not required in another. 

other words... i simply can not hard code the following text fields / drop down menus...

• first name
  
• last name
• street address 1
• street address 2
• street address 3
• street address 4
• city
• state
• zip
• country

due to another country may have the following order of how information is displayed on there envelops / packaging slips.

• street address 1
• first name
• last name
• street address 2
• zip code
• country 
• building code

opencart does have "address format" that is assigned to various countries but skimming over the entries per country, not many are filled out. only a hand full if that. 

=======================

another issue.... a person could have multi addresses assigned to them... 

• kid/user signed in, but using mom's credit card name/billing address
• kid/user signed in, but using dad's credit card name/billing address
• physical address of were they live
• physical address of were they live every other week (parents divorce'd or some such)
• items were shipped to another location
• -----------------
• other types of addresses
• -----------------
• manufacture address (billing)
• manufacture address (there shipping department)
• manufacture address (there shipping department in another warehouse)
• store locations (class room 101A, classroom 204B, etc...)
• store locations (store has multi brick/mortar locations errr physical store fronts in different cities)
• anti fraud... (when user types in there address, info is sent to an anti fraud online service, and anti fraud sends an address back either corrected (captial letters or like), or re-word for correct street name.  and needing to capture that address. so who ever is printing out package slips or manager, could click and double check what to do...

===============

i was wanting to assign a "type" to address information...  beyond user id, such as billing, shipping,store,parent, anti fraud. etc... so the same address book (code and database tables) could be used. over and over again. 

• some addresses may never be assigned to an actual "user id" 
  
• some types should never show up to "actual user"
• some should never show up in certain places.  "some block within moodle, de-noting other store locations"  example enter your zip code, to find nearby stores.  another block, for sorting out parents to child.  another block/report for sorting out multi shipping (person ordered multi things in same order but shipped to different locations, using different shipping companies)

=================

*rubs chin* looks like another simple database table. "type" = text input,  would suffice and then using the "number" from drop down menu that it builds... and assign it to one of the fields in the addressbook table.  

hhhmsss.... address formats for multi countries...  

• field required, and 
• sort order (displaying to user as they input information, and
• if displayed or not... 
• and what line information is displayed on the shipping label. and...
• if all CAPS is required or if "camel case" is needed (capitalizing first letter of each word)
  

===============

need to look into moodle "user profile code" more. to see if i can create empty usernames, first/last names, email address, etc... so certain information that can be inputted in a user profile, and then could be tied into an address book entry, so as to reduce duplication of information. **doh** create a "dummy" authentication type.  

• authentication type "dummy manufacture", 
• authentication type "dummy store location"
  
• authentication type "dummy parents address"
• authentication type "dummy etc..."
• this would allow "user creation!" and more to the point "user profile information"!! 

ok... so how do i take advantage of doing something like above?  

other words user profiles can easily be made into "address book" add a few extra fields... and then create a bunch of additional user profiles... for different address book types... but how would that impact moodle... do i really want jane doe, showing up 2 to 20 plus times... when going to assign jane doe to a given role type or enroling them into a course? do i want to edit a bunch of core code... and defining a specific user type / authentication type, so as to limit what is shown?

=============================

taking a different approach.... creating a couple functions... that "create" additional profile fields every time an addtional address was needed..  for user profile fields. meh.. that would grow the custom_field and custom_field description, custom_field_type tables out of proportion....

=============================

an ideal situation would be... taking... site admin menu -> plugins -> *pick a plugin* -> plugin manager (page) were there is a "table across top of that page. and then some options to edit/delete, a row in table. and a button to add another row to the table.   but putting this into a 'user profile page'. and a few other locations.  with some hard coding of "address type" pending on were things are listed / were information is entered.  

i think i am still going to need to create "dummy authentication plugin type and/or types" so as to create dummy accounts. meh.. still do not like idea of dummy authentication plugin.

simply creating a "manual" account. and then create a "role" say "store" or "manufacture", or "billing address" meh... still do not like that.. either. would need to find every piece of code that pulls a list of users... and "define" a type. so information is not displayed. errr i suppose setting field to "hidden".... and/or profile to hidden?  meh "hide email address from everyone" and not hide profile from everyone option...

=============================

KISS (keep it simply stupid),  removing user profiles from equation. hard code some "types" for addressbook type entries... but still use a database table for types.  so additional types can be added. but just hard code what types can display were and how in various locations. if something needs to pulls data from a user profile, then will leave it at developer in how to create a user / user profile. and/or create an addition field for the address book.  assumption some information may get duplicated. between user profiles, and addressbook. 

=============================

time to go searching on google. hopefully google will return some better results for me now. and decide to stay with opencart addressbook, or go with another software, and porting it over to moodle. 

that search ended quickly, and staying with opencart setup... for address book. but adding a "type" into the mix. it should be easy enough for folks in other countries to adjust mail format... if i hold to opencart and how it currently handles address formats. 

http://www.columbia.edu/~fdc/postal/#oz

http://en.wikipedia.org/wiki/Address_%28geography%29#Mailing%5Faddress%5Fformat%5Fby%5Fcountry

some issues, i have not seen brought up. beyond the crazy amount of address formats. 

if in united states, i put in my return address,  then put in a send to address to france...  i am not seeing a "double" sent to address one for originating country (so locals in that country can read address), but also, a second send to address, so locals in other country can read the address. i could see issue of someone not knowing other language... and not knowing how or what to do with a given send to address.

just simple looking at information i can find... it would not surprise me, to start seeing GPS coordinates start showing up as a universal standard across the world for shipping to/from physical addresses/locations for international shipping of items. leaving it up to local delivery companies to figure things out from there...

========================

i guess i will just drop addressbook into... www.yoursite.com/moodle/address

looking at...

below is from.. https://docs.moodle.org/dev/Plugin_types

and looking at code in www.yoursite.com/user/*  

it looks like i would need to do near a full copy of the user folder (files and sub folders) to address folder.  to keep it KISS (keep it simply stupid)  duplication of a lot of functions.. and doing a search and replace on them...