Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Addon Development - Best Practices


Recommended Posts

Yes @@burt - especially as I already had a style overriding it there. Now it's

<style type="text/css"> @[member='import'] url("ext/colorbox/colorbox.css"); #cboxTitle{font-weight:bold; font-size:large; color:#000000;}</style>
<div class="col-sm-<?php echo $content_width . ' ' . MODULE_CONTENT_PRODUCT_INFO_GALLERY_CAPTION_CONTENT_ALIGN . ' ' . MODULE_CONTENT_PRODUCT_INFO_GALLERY_CAPTION_CONTENT_VERT_MARGIN . ' ' . MODULE_CONTENT_PRODUCT_INFO_GALLERY_CAPTION_CONTENT_HORIZ_MARGIN; ?> productsimages">
    <?php echo $gallery_output; ?>
</div>
works a treat

 

 

Thanks a lot for that! Of all the proposals made here, this is the first that actually works for me.

 

Another question regarding css files for cm_ modules: where to put them? Into the catalog directory? The template directory? Create a new folder includes/modules/content/name/css?
 
Any suggestions?
 
J.J.
Link to comment
Share on other sites

  • Replies 130
  • Created
  • Last Reply

Agree with @@burt, but HTML is almost irrelevant anyway. Most of what we used to do in HTML can be done better in CSS.

 

That leads to another suggested Best Practice: Use HTML only as containers, not for styling, and style the containers with CSS where needed.

 

Regards

Jim.

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

Link to comment
Share on other sites

HTML5 is the way forward...

Ok @@burt and @@bruyndoncx - this version validates for html5. The link needs 'property' and the style must be scoped and the first thing in a div

<link rel="stylesheet" href="ext/colorbox/colorbox.css" property="stylesheet" />
<div class="col-sm-<?php echo $content_width . ' ' . MODULE_CONTENT_PRODUCT_INFO_GALLERY_CAPTION_CONTENT_ALIGN . ' ' . MODULE_CONTENT_PRODUCT_INFO_GALLERY_CAPTION_CONTENT_VERT_MARGIN . ' ' . MODULE_CONTENT_PRODUCT_INFO_GALLERY_CAPTION_CONTENT_HORIZ_MARGIN; ?> productsimages">
  <style type="text/css" scoped>#cboxTitle{font-weight:bold; font-size:large; color:#000000;}</style>
  <?php echo $gallery_output; ?>
</div>

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

I notice often (now that we go use html5) still use strict coding.

 

For example the -BR- tag is written in strict as <br/> , however it should be simply <br>

Same for the -img- tag

<img src="smiley.gif" alt="Smiley face" height="42" width="42" />

Simply back to old way:

 

<img src="smiley.gif" alt="Smiley face" height="42" width="42">

 

Keep in mind that html5 is loose typed for the most, however strict html is not part of it.

That is why I asked, as those strict vs loose differences annoy me when debugging and resorting to W3validation to figure out what is wrong with my tags.

 

Also things like <script> do we still need to tell if it is javascript or not.

Also is there a difference between 2.3.4 and 2.4 for what we are discussing here ?

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

Can use

<br> or <br /> or <br/> - all valid html5.

<img src=""> or <img src=""/> or <img src="" /> - all valid html5

 

Edit:

We probably should choose one and stick to it.

I propose: <br>

Reason: less to type (removing 1 space and a slash)

 

 

Remove the type="xyz" from any and all <script and <link calls.

Link to comment
Share on other sites

  • 2 weeks later...

There are radio buttons false/true where you can choose if you want to drop the tables when removing the module or not.

This option can be changed at anytime while the module is installed.

Changes are between // BOF TSIMI and // EOF TSIMI

 

http://pastebin.com/RH8Xky0X

 

Have a go and say what you think....

 

Really helpful! it works nicely. Also @@De Dokta code for checking if a field exist. These bits makes installing addons clean for users.

 

I've made a try on localization of the config options; It can be done by including the language file and adding there the titles and descriptions of the module:

 

Module file:

    function install() {
      global $language;
      include( DIR_FS_CATALOG . "/includes/languages/" . $language . "/modules/shipping/dhl.php");

      tep_db_query("insert into configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, set_function, date_added) VALUES ('" . MODULE_SHIPPING_DHL_STATUS_TEXT . "', 'MODULE_SHIPPING_DHL_STATUS', 'True', '" . MODULE_SHIPPING_DHL_STATUS_DESC . "', '6', '0', 'tep_cfg_select_option(array(\'True\', \'False\'), ', now())");

Language file:

define('MODULE_SHIPPING_DHL_STATUS_TEXT', '¿Habilitar DHL Day definite?');
define('MODULE_SHIPPING_DHL_STATUS_DESC', '¿Ofrecer esta forma de envío?');

It's not perfect because if you switch admin language it won't translate the options but it's useful on most cases.

 

Now I'm trying to find a way to localize and describe better radio buttons in config so we can have a real description for radio labels (ie. Keep data/Remove data) instead of raw value (True/False) obtained by set_function; Maybe by using use_function field? Any ideas?

 

Link to comment
Share on other sites

@@piernas  If you look at the install code for your module, you'll see

... tep_cfg_select_option(array(\'True\', \'False\') ...

That sets the selection values as True or False for that key. You can easily change that to

... tep_cfg_select_option(array(\'Keep Data\', \'Remove Data\') ...

Just remember that those values are stored as text in the database, so any test for the value of this key must match the values you actually used.

 

Regards

Jim

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

Link to comment
Share on other sites

@@kymation thanks it's useful for single language; I'm also trying to localize the radio button label. set function will use the same value for the label and for the value itself so it's language dependant. What I'm trying to do is to print a language independant string (same language as the admin selected one) for it. A trick for translating config values.

 

I've found some samples for using combo boxes when selecting, for example, an order status:

tep_db_query("insert into " . TABLE_CONFIGURATION . " (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, set_function, use_function, date_added) values ('Set Order Status', 'MODULE_SHIPPING_DHL_PICKUP', '0', 'Set the status of orders made with this payment module to this value', '6', '0', 'tep_cfg_pull_down_order_statuses(', 'tep_get_order_status_name', now())");

It uses both use_function and set_function. The raw value (order_status_id) is saved on the database config entry, but a combo with names (localized) is shown on the module config page. I'll try to do the same with combo boxes as soon as I have the time to inspect how these functions work :)

Link to comment
Share on other sites

tep_cfg_select_option() is stored in the database when the module is installed. Same with tep_cfg_pull_down_order_statuses(). You'll need to write a new function that translates internally from a language constant, then store just the function.

 

Regards

Jim

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

Link to comment
Share on other sites

Using box modules, it's easy to add fields or tables to the database on the store side. Is it possible to do the same adding (and/or deletion) of fields or tables in the admin side of the store?

 

I'm working on a report for the admin side of the store. It requires adding new fields to the database. While it is easy to run the sql code through phpMyAdmin, I'm looking for a way to make it as plug-and-play as possible.

 

Thanks!

 

Malcolm

Link to comment
Share on other sites

Using box modules, it's easy to add fields or tables to the database on the store side. Is it possible to do the same adding (and/or deletion) of fields or tables in the admin side of the store?

 

I'm working on a report for the admin side of the store. It requires adding new fields to the database. While it is easy to run the sql code through phpMyAdmin, I'm looking for a way to make it as plug-and-play as possible.

 

Thanks!

 

Malcolm

 

If it's a dashboard report, you can put it in the install like catalog modules, while if it's a page in the reports box, test the database at the top of the script. That's what I've done in the addons I'm converting that have an admin page, eg. cross-sell (see admin/xsell.php in https://github.com/BrockleyJohn/Responsive-osCommerce/tree/cross_sell_addon

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

  • 5 weeks later...

Disagree. Addons sould contain at least english, AND optionally add any other language the author could decide. It makes life easier for non-english speakers.

Link to comment
Share on other sites

Suggestion: Include only English in the addon, and upload additional languages as separate addons. This allows the shop owner to choose the language(s) that they want, and not have additional unwanted languages cluttering up the install.

 

Regards

Jim

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

Link to comment
Share on other sites

Sorry you do not agree @@piernas

Perfect suggestion @@kymation

 

An alternative would be to have the main addon as english only, and then in the support thread have extra downloads for languages as they are created (either by the addon creator or users of the addon...).   Threads can now accept .zip attachments

 

In general, I do believe that keeping things "clean" will benefit addon users.

Link to comment
Share on other sites

Suggestion:

Additional languages in a separate folder, but in the same package.

Link to comment
Share on other sites

@@piernas

@@raiwa

 

I have taken existing add-ons for older versions of osC that included multiple languages, and updated them for v234 (or v234bs). In doing so, if I had to revise the language files, I could only revise the English file, as I did/do not speak the other languages.

 

In this case, would you prefer that I include incomplete other-language files, or not include them at all?

 

Malcolm

Link to comment
Share on other sites

@@ArtcoInc,

 

I believe it's better to revise then to begin from zero the translations.

You can just add an advice to the instructions.

Link to comment
Share on other sites

@@burt yes that would be a good solution but current download addon section can be very confusing for that purpose. It would need some sort of filter or clasification to easily find the language files for an specific addon version,say:

 

  • Addon V 2.1 (link)
    • Greek language for 2.1 (link)
    • Dutch language for 2.1 (link)
    • Spanish language for 2.1 (link)
  • Addon v 2.2
    • Greek language for 2.1 (link)
    • Dutch language for 2.1 (link)

@@ArtcoInc yes that's a problem. With current install method I'd prefer a partial file so most of the work is already done and just add/translate the few missing constants.

 

@@raiwa @@kymation if the database language work from @@wHiTeHaT is included it would be easy to add a routine that installs only the languages needed (if they exist in the downloaded package) or default to english if not. Anyway manually deleting a language file is not as complex than translating it from zero. Removing unneeded files is the first thing I do for downloaded addons.

 

Personally I don't translate admin side addons (just install in spanish if the file exists, if not I simply rename english.php to espanol.php and that's it), but I always do for shop side for customers.

Link to comment
Share on other sites

I just read quickly through this thread and I see that we had some good ideas as to make things easier.

We got database changes, custom css additions.

 

But what about javascript codes inside the modules? If I am not mistaken those js codes get loaded inside the header area (template_top.php) right?

I had a case where the javascript just didn't work inside the template_top.php so I needed to move the js code to the template_bottom.php file which means I needed to amend core code.

To avoid such changes why not add this following codes inside a module that allows the user to choose where the JS code should be loaded from.

(Example is for a header tags module.)

 

Inside the "execute" function add

if(MODULE_HEADER_TAGS_XXXX_JS_PLACEMENT!='Header') { $this->group = 'footer_scripts'; }

then below inside the "install" function add

  tep_db_query("insert into " . TABLE_CONFIGURATION . " (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, set_function, date_added) values ('Javascript Placement', 'MODULE_HEADER_TAGS_XXXX_JS_PLACEMENT', 'Header', 'Should the javascript be loaded in the header or footer?', '6', '1', 'tep_cfg_select_option(array(\'Header\', \'Footer\'), ', now())");

and don't forget to add MODULE_HEADER_TAGS_XXXX_JS_PLACEMENT to the "keys" function below it.

Also replace XXXX with what ever name your module has.

Link to comment
Share on other sites

@@Tsimi

 

Random thoughts;

 

1. the choice between header/footer exists already in (eg) one of the Google HT modules.

2. if the js you need only works in the Footer, why give a choice between header and footer

3. get out of the habit of using TABLE_*

 

If I am not mistaken those js codes get loaded inside the header area (template_top.php) right?

Only if the coder made it that way...they can be loaded also in the footer, or from 1 module a mixture of both.

Link to comment
Share on other sites

@@burt

 

1. didn't know that.

2. In my case, true, it is not necessary anymore but the situation I faced gave me something to think and that was the result. Others might not have that problem and "then" it might be good to have.

3. That "sample" code is from the GOLD version and I didn't wanna touch "core code" :P ;) so....

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...