Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

OsCommerce v 2.3 - when?


scandic_outlet

Recommended Posts

  • Replies 373
  • Created
  • Last Reply

So you are looking for a "google base" submission with title, description and few other fields which includes image link etc? I am not following your point..

 

 

I can see why you say that ... but you've missed a whole bunch of the obvious.

 

Using only what Google wants for each product, let's look at a few possibilities ....

 

Field - Colour : Leads to the possibility of pseudo-categories based around colour availability for products - example markets being - wedding planners, interior designers, sports team fans, and so on. osC currently has no default field for colour.

 

Field - Country of Origin : Leads to filter in / filter out of product source as per the current anti-Chinese hysteria sweeping America's online citizens this year. osC does not have a field for this, despite it being a legal requirement when selling in Europe, and for anything that crosses any national border.

 

Field - Size : Leads to site front page option of "show me what you got in my size and don't show me anything else". Have you ever seen an option like that on ANY ecommerce store? Can you imagine the time saving and shopper-stickiness it would cause? This is the number one search priority in the clothing niches (after gender and garment type - trousers, dress etc).

 

Put it together - I want to see everything you've got in my size, in black, that's made in the UK. Click. Wham - your very own personalised catalogue for this site. Sticky Shopper Central boys and girls. eCommerce Success with a capital Dollar.

 

Now, here the options

- bung it in core and let every osC user have it,

- custom code it and keep it for your own site only,

- or make it a contrib, and sit back to watch every other cart script have it in their core before even 5% of the osC user community know it's available as a contrib.

 

What we're talking here is modern search filtering. Google's attributes are just a convenient starting skeleton because using their full list covers 99% of bases. Custom fields could be allowed for too, in much the same way as the countries and currencies lists in osC don't restrict you to just the ones shipped in the box. Of course, by using Google's skeleton, you also get the benefit of better product feeds and search placement.

 

(Side note - a few minutes ago, I just read an article that Bonanza are now not only using this to submit to Google, but have also added the same for Microsoft's Bing search engine, and are submitting their vendor's inventory hourly. Other marketplaces will follow this lead quite soon. The more these 3rd party marketplaces show own-site developers the way to market, the lower the demand will become for own-site vending. If osC doesn't embrace and incorporate this sort of stuff soon, the only market for the script will become non-vending developers looking for a platform to hang their coding hat onto.)

 

As my marketing mentor would say - stop thinking about the sausage ... and smell the sizzle.

 

So you want to sell your osC inventory on Amazon? What's the bar code number? Oh dear, that's not recorded in osC. What's the country of origin? Oops, blush, dunno. What's the product condition? Ermmmm? What edition is that book? Huh?

 

You see? There's so much information missing from the stock (both senses of that word) fields in osC. And the worst part is, that these are information items that customers request time after time after time - even if you put them in the description narrative. They just don't see them unless they're tabular, or in drop down search criteria lists. Dumb and catch-22 I know, but it's the truth of it.

 

These are basic product informations that should be on every appropriate product page. Holding them in the database allows conditional queries to omit blank lines, and to update by fields (did someone say CSV import?) rather than rewriting/recoding descriptions. The target is - make it easy for the customers, and they'll spend more each time, and return more often.

Wearing a seatbelt prevents head injuries when the computer crashes - - - Yeah Right!!! - not in this office.

Link to comment
Share on other sites

Hi Gary..

 

What about using grid_24 and creating your two (custom) divs in there?

 

Kind regards,

 

 

You mean nested divs, the same way as you can nest tables?

 

That defeats the purpose of grid system skeletons - they're designed at the most basic concept level, around having a div as an object that can be shuffled (with contents) as per floating widgets and dynamic sidebars.

 

Then you have to consider the z-align issue as well, and overlapping and interleaving divs as part of the design, based on which layer the div is in - grid systems are not really geared towards this - they're more for laying out a pile of playing cards side by side in columns and rows. Not saying you can't do it, but it becomes a lot trickier than just coding raw onto a blank screen - how do you position a .grid-6 to be half in one column and half in another? Yeah you could add id's and absolute positioning etc, but freehand you just add a margin or padding value to a unique (meaningful) div class name.

Wearing a seatbelt prevents head injuries when the computer crashes - - - Yeah Right!!! - not in this office.

Link to comment
Share on other sites

I don't think you guys are looking at the grid system quite right.

 

The grid system is essentially your piece of paper. It's not meant to be designed, it's meant to contain design.

 

The grid system is your jumping off point, which sets your absolute limits. The designer can then create <div class="myStyle"></div> and use this to wrap their content using % based css values. Or better yet, seting values for specific tags would easily create a nice sitewide theme.

 

Personally I'm thrilled with the 960 grid.

 

Quick Question: Did anyone actually prefer the nested table layout? lol

 

 

Amazon & Google Base Attributes

 

Are something that aren't widely enough used for them to be included in the core code of osCommerce. They are perfect examples of why Add-Ons exist.

 

(Just so you know, I use both, and would love properly coded and verified add-ons or core components for this functionality, but it isn't inline with the ideals of the osCommerce team.)

A little knowledge of php goes a long way.

Link to comment
Share on other sites

Hi Harald

 

Certainly can do, but then that negates the whole point of the gridded system?

 

960 is usable, but not really when you start looking more deeply (if that makes sense lol).

 

There are several ways to accomplish borders even without nesting div's. Google 'borders' and '960 grid'. Here, however is a simple example of how to create two nicely centered boxes, spread all the way across the page in OSC 2.3 with thick red borders, without nesting tables:

 

<style>
.grid_5{
border:5px solid #FF0000;
}
</style>

<div class="grid_11 alpha push_1">some content</div>
<div class="grid_11 push_1 omega">more content</div>
<div class="clear"></div>

 

 

You can even stack the boxes, divs, on top of each other. Without making any changes to the stylesheet, this will center the text on any 2.3 page with one div on top of the other.

 

<div class="grid_12 alpha push_12">content above </div>
<div class="grid_12 omega">content below</div>
<div class="clear"></div>

 

You can combine classes for even more sophisticated alignment.

 

Contrary to being limiting, the 960grid or other grid system open up potential to do really neat stuff easily and quickly.

 

To see what the professionals have done with the 960, view this selection of sites, right on the front page of http://960.gs/:

Oscommerce site:

 

 

OSC to CSS, http://addons.oscommerce.com/info/7263 -Mail Manager, http://addons.oscommerce.com/info/8120

Link to comment
Share on other sites

- or make it a contrib, and sit back to watch every other cart script have it in their core before even 5% of the osC user community know it's available as a contrib.

<snipped>

So, that means less than 5% of the users have found it, right? Considering that the addon has been up for a year now, and I haven't seen any other cart with this functionality. Or maybe I just need to spend more time looking at other carts.

 

Regards

Jim

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

Link to comment
Share on other sites

You mean nested divs, the same way as you can nest tables?

 

That defeats the purpose of grid system skeletons - they're designed at the most basic concept level, around having a div as an object that can be shuffled (with contents) as per floating widgets and dynamic sidebars.

 

Then you have to consider the z-align issue as well, and overlapping and interleaving divs as part of the design, based on which layer the div is in - grid systems are not really geared towards this - they're more for laying out a pile of playing cards side by side in columns and rows. Not saying you can't do it, but it becomes a lot trickier than just coding raw onto a blank screen - how do you position a .grid-6 to be half in one column and half in another? Yeah you could add id's and absolute positioning etc, but freehand you just add a margin or padding value to a unique (meaningful) div class name.

 

Learn how to use the push_x and pull_x classes. They are a quick and easy built-in way in the 960 gs system to overlap div's into adjacent columns, and to even stack div's in layers. Just add the appropriate class, you don't even need to open the stylesheet. You're missing the strength of the grid system if you think of them as cards laid out side by side.

 

nesting: To begin with all the grid classes in the 960gs are nested within a container class. The point of the grid system is not eliminate nesting. The grid system even provides you with special classes to facilitate nesting.

Oscommerce site:

 

 

OSC to CSS, http://addons.oscommerce.com/info/7263 -Mail Manager, http://addons.oscommerce.com/info/8120

Link to comment
Share on other sites

So, that means less than 5% of the users have found it, right? Considering that the addon has been up for a year now, and I haven't seen any other cart with this functionality. Or maybe I just need to spend more time looking at other carts.

 

Regards

Jim

 

Hi Jim,

 

Which contribution are you referring to, so we are all looking at the same thing. :thumbsup:

Link to comment
Share on other sites

I can see why you say that ... but you've missed a whole bunch of the obvious.

 

Using only what Google wants for each product, let's look at a few possibilities ....

 

Field - Colour : Leads to the possibility of pseudo-categories based around colour availability for products - example markets being - wedding planners, interior designers, sports team fans, and so on. osC currently has no default field for colour.

 

Field - Country of Origin : Leads to filter in / filter out of product source as per the current anti-Chinese hysteria sweeping America's online citizens this year. osC does not have a field for this, despite it being a legal requirement when selling in Europe, and for anything that crosses any national border.

 

Field - Size : Leads to site front page option of "show me what you got in my size and don't show me anything else". Have you ever seen an option like that on ANY ecommerce store? Can you imagine the time saving and shopper-stickiness it would cause? This is the number one search priority in the clothing niches (after gender and garment type - trousers, dress etc).

 

Put it together - I want to see everything you've got in my size, in black, that's made in the UK. Click. Wham - your very own personalised catalogue for this site. Sticky Shopper Central boys and girls. eCommerce Success with a capital Dollar.

 

Now, here the options

- bung it in core and let every osC user have it,

- custom code it and keep it for your own site only,

- or make it a contrib, and sit back to watch every other cart script have it in their core before even 5% of the osC user community know it's available as a contrib.

 

What we're talking here is modern search filtering. Google's attributes are just a convenient starting skeleton because using their full list covers 99% of bases. Custom fields could be allowed for too, in much the same way as the countries and currencies lists in osC don't restrict you to just the ones shipped in the box. Of course, by using Google's skeleton, you also get the benefit of better product feeds and search placement.

 

(Side note - a few minutes ago, I just read an article that Bonanza are now not only using this to submit to Google, but have also added the same for Microsoft's Bing search engine, and are submitting their vendor's inventory hourly. Other marketplaces will follow this lead quite soon. The more these 3rd party marketplaces show own-site developers the way to market, the lower the demand will become for own-site vending. If osC doesn't embrace and incorporate this sort of stuff soon, the only market for the script will become non-vending developers looking for a platform to hang their coding hat onto.)

 

As my marketing mentor would say - stop thinking about the sausage ... and smell the sizzle.

 

So you want to sell your osC inventory on Amazon? What's the bar code number? Oh dear, that's not recorded in osC. What's the country of origin? Oops, blush, dunno. What's the product condition? Ermmmm? What edition is that book? Huh?

 

You see? There's so much information missing from the stock (both senses of that word) fields in osC. And the worst part is, that these are information items that customers request time after time after time - even if you put them in the description narrative. They just don't see them unless they're tabular, or in drop down search criteria lists. Dumb and catch-22 I know, but it's the truth of it.

 

These are basic product informations that should be on every appropriate product page. Holding them in the database allows conditional queries to omit blank lines, and to update by fields (did someone say CSV import?) rather than rewriting/recoding descriptions. The target is - make it easy for the customers, and they'll spend more each time, and return more often.

 

 

Somewhere you lost me completely. My question was just about google and I guess you can add bing too..how difficult is it to add more fields in database to extract the data in order to construct either an xml file or tab file to submit products.

Link to comment
Share on other sites

Hi Jim,

 

Which contribution are you referring to, so we are all looking at the same thing. :thumbsup:

Products Specifications will add the additional product data fields and allow customers to filter on the values in those fields. You'd have to add the additional fields to your Google feeder; that part currently doesn't exist. I'll add that to my wishlist.

 

Regards

Jim

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

Link to comment
Share on other sites

So, that means less than 5% of the users have found it, right? Considering that the addon has been up for a year now, and I haven't seen any other cart with this functionality. Or maybe I just need to spend more time looking at other carts.

 

Regards

Jim

 

 

Jim

To which contrib are you referring?

 

The various product feed submitters only use stock osC product fields - they don't add any of the product attributes the search engines want in order to boost your search ranking

 

The various extra-fields plugins do not have product submitters embedded. One of them is searchable on-site by only one custom field at a time. Another force embeds 777 permissions on uploaded images (major security hazard - I got hacked twice via that before I identified the problem source).

 

What I'm suggesting is to bring the in-osC product attributes and fields up to the same level as most of the rest of the various involved softwares, and there is currently neither core nor contrib that provides what I suggest outside of the 3rd party marketplaces.

 

I still don't follow why there is resistance to adding something that -

a. Is a requirement of the web's largest search engines (and therefore 95% plus of the search engines used)

b. Improves the shopper experience by making custom searches more flexible, and results more logical

c. Would certainly lead to more sales via improved search ranking and stickier customers

 

Sheesh - makes me think you're all more bothered about staying archaic than you are about actually using osC to sell products and make money (for yourself or your clients).

 

Product attributes for search engines like Google, Bing, and Yahoo, and for shopping portals like Froogle et al, should be a high priority in the increasingly competitive ecommerce space - - - OK, if I was talking about "Sweaty Steve's Shopping Search" with maybe 1,000 users world wide, then fair enough, keep it in contrib territory, but what I'm proposing here relates to feeding the 800 lb gorillas, not the performing monkeys.

 

Failing to provide either an embedded core function for custom fields, or a core system (similar to the currencies and countries and languages ones) for product attributes, if not crippling to store capabilities, is certainly hobbling it to a limp-along performance rather than allowing it to sprint.

 

:rolleyes: You can lead horses to water ....

Wearing a seatbelt prevents head injuries when the computer crashes - - - Yeah Right!!! - not in this office.

Link to comment
Share on other sites

Products Specifications. I was referring to the previous discussion on extra data fields and filters using those fields, which is what PS was designed to do. Exporting those fields to a Google feeder is not part of that Addon, but could be easily added. Nobody has asked for that feature so far.

 

While I agree that this is a good idea, I believe that only a small percentage of osCommerce stores use a Google (or similar) feeder, so getting it into the core code is unlikely. Maybe if the Addon is popular enough it will happen.

 

Regards

Jim

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

Link to comment
Share on other sites

Somewhere you lost me completely. My question was just about google and I guess you can add bing too..how difficult is it to add more fields in database to extract the data in order to construct either an xml file or tab file to submit products.

 

 

Hi Spoofy

 

It's a multi-layered answer ;)

 

Adding more fields to the database is dead easy - just add a new table and "fill yer boots" so to speak.

Adding them to the input side of the site is easy-ish - open categories.php and edit away.

 

Of course, you then need to also add the code to categories.php to save them to the database, together with the index key for the product you're adding, and link your new table entry to your original products table(s).

 

Then you need to output your new info to screen, this is probably the easiest part - extending the queries and display of results in the products output - add some ice and a slice of lemon, shake and stir in your css, and voila. However that doesn't yet include customer selected search priorities, which you'd need to code (and design the presentation, options, and results output for it too). Drop down lists of existing-in-database main fields may be the route to go here.

 

Then you'd need to open up a feed contrib (Google Feed or Google Feeder or something like that) and perform some spaghetti straightening to find out where to add the meat chunks for your new fields, input Google formatted attribute names, translate from your assigned field names to Google's ones, grab the relevant fields contents and so forth, test, debug, test again and so on. You'd need to add an attributes name translator for each search engine's naming system, and a currency conversion for the currency they allow (easy using existing osC functions if your allowed display currencies list is already set up) mash it all together and serve it in the XML format demanded by the products feed recipient. Choose whether to cache an xml file in a "open" folder for all to see, or to dynamically create a virtual xml file when the feed requestor asks for it - code appropriately.

 

Yes, there's a fair chunk of work involved, and if it were to be made into a major (osC 3) module, then it should certainly be multi-destination enabled (e.g. for each Google country, and for the other search engines too) - all this before even thinking about building the feeder system to reserve inventory and send it to 3rd-party marketplaces.

 

If there's enough genuine interest in it, and enough capable coders thinking of tackling it, maybe we could make it into a collective effort and run a team on it - if all of the "dream sheet" were to be built in, it would be a major project and because of the multi-facet nature, best suited to team-development than to a single coder .... just thinking aloud there.

 

For osC core - there's a separation point -

I'd suggest the Google attributes list and store-owner custom fields should be enabled in core, but the non-basic output from that data should be contrib territory (for anything beyond a conditionalised ordered list on the product page - perhaps as a core default, outputting it in a "product data side-box" under the main image, or above or below the main narrative description).

 

Then, with it in core like that, the feed and API tools-developers can use it to their hearts' content, meanwhile, organic search has a whole new world of per-product "keywords" to index for each product - configure the core basic output as <h5> emphasised to gain SEO weighting. Meta-tags contribs (or raw coding) could grab the attribute contents and use it for standard SEO work.

 

 

..... more thinking aloud - Harald - perhaps the forum needs a special area for brainstorming/discussing topics like this one?

Wearing a seatbelt prevents head injuries when the computer crashes - - - Yeah Right!!! - not in this office.

Link to comment
Share on other sites

Products Specifications. I was referring to the previous discussion on extra data fields and filters using those fields, which is what PS was designed to do. Exporting those fields to a Google feeder is not part of that Addon, but could be easily added. Nobody has asked for that feature so far.

 

While I agree that this is a good idea, I believe that only a small percentage of osCommerce stores use a Google (or similar) feeder, so getting it into the core code is unlikely. Maybe if the Addon is popular enough it will happen.

 

Regards

Jim

 

 

I'll have a look at the plugin in a moment, however your second paragraph is a self fulfilling prophesy - if it's not there, then people can't use it.

 

If the osC contribs system showed cumulative downloads for each contrib, we'd have a much better understanding of the demand - my belief is that a very large number of people use the feed contrib - if you've ever hung around on any eBay or similar "Pro" discussion boards, you'd soon see that all those with own-stores are submitting to search engines, and though they're a small sample of the larger vendor-base on 3rd-party marketplaces, they are a very representative sample. I'd argue that significantly over 50% of the user base of osC are feeding to search engines in one form or another.

Wearing a seatbelt prevents head injuries when the computer crashes - - - Yeah Right!!! - not in this office.

Link to comment
Share on other sites

Kymation - your contrib doesn't state which version of osC it is coded for, nor does it have an osC forum linked for discussion and help.

 

It also uses entirely custom configurable fields - without the structured lists of the search engines (that's both a good and bad thing - especially for newbies who could create complete chaos in their data).

 

Looks interesting though, and maybe a step forward on earlier (more popular) versions of a similar idea.

Wearing a seatbelt prevents head injuries when the computer crashes - - - Yeah Right!!! - not in this office.

Link to comment
Share on other sites

You want to know what resource hog is? Try Magento and then come back.

 

That is largely a myth these days and has been for quite some time. I have both an osCommerce and a Magento site running on the same server. Performance is easily within 1% of each other. All it takes is a little bit of time and knowledge. Of course, throw a default install of Magento on a cheap ass shared server and don't use any of it's caching functionality, and it'll run like crap. But businesses should never run their site on shared hosting, for reasons completely unrelated to performance.

 

Regarding the rest of this thread, we need a giant Picard smiley for some of the crap being posted. I'm not gonna go through it all post by post though because it would take forever. All I can say is that I like the direction osCommerce is heading now. I think 2.3 should have been strictly a bug fix release, but ANYTHING new is welcome instead of the years and years of pretty much nothing. While I've largely switched to Magento for my e-commerce needs, there are still plenty of cases where it's massively overkill and too much hassle to mess with, especially for smaller sites. I just picked up a new client recently, and osCommerce 2.3 should serve as a nice base for the needs of this site. Keep up the good work.

Link to comment
Share on other sites

It's 2.2RC2a. I'll update it to 2.3 whenever that stabilizes enough to attempt. Links to the support thread and a bugs/wishlist thread are listed in the description.

 

The use of completely customizable fields was part of the design criteria. It would be extremely simple to provide an option to setup Google compliant fields -- that's just a bit of SQL Other feeder-compliant fields can be added the same way. The store owner/programmer would have to link the added fields to their categories, but that needs only one click to enable the entire store.

 

Regards

Jim

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

Link to comment
Share on other sites

Go for it Jim

 

My belief is that getting more osC site-owners leveraging the shopping search platforms can only be good for the reputation of osC, as those shop owners begin to see better and better sales results from the script.

 

Outside of the corporates, there is a real buzz amongst small vendors about adding product feeds to the search engines - it's becoming a must-have feature, if it's not one already.

Wearing a seatbelt prevents head injuries when the computer crashes - - - Yeah Right!!! - not in this office.

Link to comment
Share on other sites

Do you have the field requirements for Google et al, or a source for all of them? This is more likely to happen if I don't have to hunt all over for dozens of different feeder specs.

 

Regards

Jim

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

Link to comment
Share on other sites

The use of completely customizable fields was part of the design criteria.

 

There is another, in my view very important, feature: full customizable address fields for customer, shipping and invoice addresses. Because I know how hard it is to implement customizable product and address fields correct (afaik "even" Magento hasn't customizable address fields), I fully understand why these two features aren't built into osC 2.x but I hope they will be considered for OSCOM 3.x

 

EDIT: Also valuable would be full/additional customizable order fields e.g. when a customer wants to mark his order with a reference (internal purchase reference) so that he can identify it later when it will be delivered

Specialist in end-to-end integration between osCommerce and Microsoft Dynamics NAV ERP System

About Pronux | Pronux Contributions and Add-Ons

Link to comment
Share on other sites

Jim - check back a dozen posts or more - I posted the links to them

Found them -- Thanks! I'm working on an update to Products Specifications right now. I'll try to get this folded in. At least the new fields.

 

Regards

Jim

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

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...