Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Addon Development - Best Practices


Recommended Posts

I have been adapting some older add-ons to work with osC 234 Responsive for use in my store(s), and I might like to share some of these back with the community.

 

Many existing add-ons modify a number of files, including possibly some 'core' files. For example, a recent add-on I was working on required changing (amongst other files):

 

catalog/includes/filenames.php

catalog/includes/database_tables.php

catalog/includes/languages/english.php

 

catalog/admin/includes/filenames.php

catalog/admin/includes/database_tables.php

catalog/admin/includes/languages/english.php

 

Couldn't some of these changes be avoided if the referenced file names and database tables were 'hard coded' into the add-on?

 

Couldn't (shouldn't?) the text definitions be put into an add-on specific language definition file, instead of the default english.php?

 

Couldn't any CSS statements be 'hard coded' into the add-on, instead of requiring an edit to the user.css file?

 

Likewise, couldn't the creation of new database tables be coded into the add-on, instead of requiring a manual SQL step during the installation?

 

 

So, in as much as I am trying to have any new add-on to be as "copy/install/configure/go" as possible, what are the 'Best Practices' for putting together an add-on?

 

Malcolm

Link to comment
Share on other sites

  • Replies 130
  • Created
  • Last Reply

@@ArtcoInc

 

Malcolm, you won't get any arguments on whether the file names and database table names should be hard coded...see this post from Gary.

http://www.oscommerce.com/forums/topic/402638-discussion-about-hard-coded-database-tables/?p=1718525
 

@figuera - database names and filenames should be hardcoded.  

/includes/filenames.php and /includes/database_tables.php are deprecated.

 

Assuming you're adding these as content modules there should also be a language file in the specific language content module directory although these languages files will also be updated in future releases to .ini files I believe. 

 

For the css I would favor a separate .css file that can just be uploaded along with the other module files.   It would be specific to the particular content module.  I'm not sure that is the best way but all of this should keep you out of the core and leave you with contributions that you can simply upload to the specific directories and then install.

 

Thoughts anyone?

 

Dan

Link to comment
Share on other sites

@@Dan Cole

 

I was just about to say that adding a separate CSS file require adding to template_top.php, but I then realized that one can call a CSS file anywhere. The only problem I see there is that developers would have to use a naming convention that would prevent CSS attributes in different add-ons from being called the same thing, and having the CSS file from one add-on override another.

 

Malcolm

Link to comment
Share on other sites

@@ArtcoInc

 

If it is specific to the module (ie only called by your module) it should be no different than including it in the module itself and shouldn't interfere with any other module. At least I don't think it will.

 

Dan

Link to comment
Share on other sites

The problem with inline CSS is that it is harder to find and change. Since content modules already have a template, adding a CSS file in the template directory would be my preferred solution. Any better ideas?

 

Regards

Jim

See my profile for a list of my addons and ways to get support.

Link to comment
Share on other sites

there should be a hook command for adding stylesheets and js file links to the head section, that would be the preferred way.  That would also allow for "auto" minifying and combining scripts/css. 

Link to comment
Share on other sites

it is in basic 2.3.4 and used by the (content / box / header tag) modules.

it is i think the most important bit of recent releases as it opens the door to a lot more separation and cleaner code

KEEP CALM AND CARRY ON

I do not use the responsive bootstrap version since i coded my responsive version earlier, but i have bought every 28d of code package to support burts effort and keep this forum alive (albeit more like on life support).

So if you are still here ? What are you waiting for ?!

 

Find the most frequent unique errors to fix:

grep "PHP" php_error_log.txt | sed "s/^.* PHP/PHP/g" |grep "line" |sort | uniq -c | sort -r > counterrors.txt

Link to comment
Share on other sites

When an add-on requires the creation of new database tables or fields, the current method requires manually running the SQL code in something like phpMyAdmin. Couldn't this be added to the installation code in the add-on?

 

And, if so, this raises a couple more questions:

 

* Most add-ons have in the SQL code to check to see if the new tables already exists, and if they do, drop them before creating new ones. Is this really a 'best practice'?

 

* When an add-on is un-installed, should it delete any new tables or fields it created?

 

Thoughts?

 

Malcolm

Link to comment
Share on other sites

Awesome...I am following so far...

 

Now...let's take FWR's USU5 as an example...there will be time that the core/application flow would have to be hacked to get the USU5 logic into application_top so any thoughts on that? Or an one page check out module...Magento is such a hog I recall the userland if it exist would clobber the core hence one reason for the heavy heavy codes...I am all for not having my butt glued to a chair for three months during my next major upgrade....thx!

 

Tim

Link to comment
Share on other sites

@@ArtcoInc  If the addon created new database tables, they should probably be deleted if the addon is uninstalled. Otherwise you are leaving unused data behind that just clutters up the database. I do think that the addon should warn the user that data will be lost when it is uninstalled though.

 

Dropping the table before install would be on a case-by-case basis. Why is the table there if you  expect to install it for the first time? Is some other addon using it? Did you fail to delete it in a previous uninstall? I would be more inclined to check whether there is data in the table and leave it alone if it exists and is populated. However, if I need to replace that data anyway, and no other addon is using it, dropping and reinstalling is probably good practice.

 

@@clustersolutions  Some addons will probably still need to modify core code, at least until we get enough hooks built into the core that it is possible to do without modification. The idea is to keep the modifications to the minimum.

 

If you do have to modify core files, the addon should check that the modifications have been made and alert the user if they have not. Similarly, if an addon module has more than one file, it should check for the existence of the other file(s) and warn the user if they are not present.

 

I offer the Theme Switcher addon as an example of this. Take a look at the code, and please borrow those test functions for your own addons. Remember, the more errors that your code finds, the fewer support posts you have to answer.

 

Regards

Jim

See my profile for a list of my addons and ways to get support.

Link to comment
Share on other sites

@@kymation, hmmm...it seems like 3.0 is the way to go but I don't know if I can hold my breath for that long...

 

Now, addon that do a self checking for the necessary mods is a solution but as it is open source I don't know if the control is in place for that...the pros and cons could balance each others out.

 

Jim, and anyone else who has been at this game for a long time...any thought on a quick fix similar to the Magento method I had mentioned above. It would be nice to be able to get something like that into the 2.4.X...

 

We could be at the 2.4.x for a while...

 

 



If you do have to modify core files, the addon should check that the modifications have been made and alert the user if they have not. Similarly, if an addon module has more than one file, it should check for the existence of the other file(s) and warn the user if they are not present.

 

I offer the Theme Switcher addon as an example of this. Take a look at the code, and please borrow those test functions for your own addons. Remember, the more errors that your code finds, the fewer support posts you have to answer.

 

Link to comment
Share on other sites

"Quick fix" and "Magento" do not belong in the same sentence. :P

 

I believe that there are plans to add something like that to osCommerce, but probably not in 2.4. That will still not fix the case where two addons want to replace the same core file. It may never be possible to eliminate all conflicts.

 

Regards

Jim

See my profile for a list of my addons and ways to get support.

Link to comment
Share on other sites

Opencart 2+ has an interesting system in place for core modification, its called ocmod. (and/or and extension called vqmod)

 

In short what it does is make a copy of the core files where modifications are done according to an xml instruction file, then the copy file will be used instead of the core file.

 

This makes adding extensions and updating the core fast and easy.

 

Its not perfect, has restrictions and conflicts do happen, but its still an interesting way of doing things and might give some food for thought.

Link to comment
Share on other sites

It is not difficult for addon makers to each have their own naming system for new tables. As an example, I could use "clubosc_gallery" for that Image thing I made. Who else is ever going to use the prefix "clubosc" ? Same for a column inside an existing table; clubosc_products_xyz

 

As for destroying data when a module in uninstalled, that should be up to the shopowner, perhaps by way of a tickbox "destroy data [ ]". I was working with an addon the other day (will remain nameless) and was dismayed to find it was dropping the table on uninstall. This is not the way forward. What happens if shopowner wants to (eg) move a module from header to index page. The module needs to be uninstalled, now all the data is lost - that's plainly incorrect in some circumstances.

 

The way forward is to allow the shopowner the opportunity to;

 

1. easily (un)install code by way of module, hook, etc.

2. easily retain or nuke data

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...