OsCommerce v 2.3 - when?

[totalnumpty]

Gaz,

 

You have some good points. If you want to design a website like a branching tree, then you may be better off using something other than the 960 grid. If you want to layout your design like a checkerboard or a newspaper then the 960gs system is super efficient. It is a 'grid' system after all.

 

If you prefer laying out the 'page, wrapper, background, container, header, sidebar-left, content, sidebar-right, footer, sidebox, content-box', etc every time you create a website, then don't use a grid system like the 960gs. You'll miss those hours of fun and learning.

 

Jquery: if you prefer to write your javascript programs from scratch don't use it. If you don't like javascript at all, then you might not wish to use OSCommerce, it makes good use of it throughout the shop.

 

PS - Did you really use Frontpage for 10 years or so?

 

 

Thanks for the understanding of where I'm coming from.

 

and yes, :blush: I did rely on FrontPage for about a decade. That's what happens when you're too busy churning out sites to have time to learn alternative methodologies.

 

For Mark Evan's info - it's also why some of us have strong objections to major core code changes arriving simultaneously with entirely new ways of laying up sites - look at what happened to WordPress with v3.0 - they had to pre-announce a development moratorium knowing they'd need to actively support the user-base after the massive code and design changes in v3. No new WordPress versions for 6 months was the decision. What's osC going to do when v3 rolls? No new versions for 6 years? .... oh, forgot - you've already been there and exceeded that, haven't you? :P

 

If osC 2.3 had an official pre-release version available outside of GitHub, a lot more people (including me) could have had a play with it a lot sooner, and thus time to thoroughly familiarise ourselves with it before final version arrived. Throwing in the 960 system as a last minute addition is a real curve ball, and you have to expect resistance from some sides of the user community. Personally, I don't have time to muck around and experiment with the unstable and constantly changing code base versions of a CVS system, now it looks like plans cannot also be made against expected final version contents.

[npn2531]

Gaz, if you spent 10 years 'churning out' websites with a defunct WYSIWHG instead of learning an 'alternative methodology' like CSS, then I can understand why changes in 2.3 are distressing to you.

[MrPhil]

@MrPhil #166 - semantics I know, call it lazy typing if you will, textspeak if you prefer - I often shorten javascript to just java when posting in forums - same way as "Phil" is the shortform of your proper name.

1) You may realize that Java and Javascript are two entirely different things, but your practice just helps spread confusion among the ignorant masses.

 

Me: What color is that traffic light?

You: Green

(CRASH!)

Me: You said the light was green!

You: Red, green, whatever. I just use my system.

 

2) "Phil" is my full legal proper name. It's not a nickname. So there! (Don't call me Phillip!)

[spoofy]

1) You may realize that Java and Javascript are two entirely different things, but your practice just helps spread confusion among the ignorant masses.

 

Me: What color is that traffic light?

You: Green

(CRASH!)

Me: You said the light was green!

You: Red, green, whatever. I just use my system.

 

lmao! very nice! :lol:

[totalnumpty]

1) You may realize that Java and Javascript are two entirely different things, but your practice just helps spread confusion among the ignorant masses.

 

Me: What color is that traffic light?

You: Green

(CRASH!)

Me: You said the light was green!

You: Red, green, whatever. I just use my system.

 

Ah - so you've driven in Thailand then have you?

That's exactly how the locals apply the traffic light system here.

Seriously - not joking.

 

2) "Phil" is my full legal proper name. It's not a nickname. So there! (Don't call me Phillip!)

 

OK - I won't call you Phillip - is Philip OK?

[totalnumpty]

Gaz, if you spent 10 years 'churning out' websites with a defunct WYSIWHG instead of learning an 'alternative methodology' like CSS, then I can understand why changes in 2.3 are distressing to you.

 

 

(Replying to your pre-edited post as well - email notification is useful sometimes ;) apologies - sequencing got mucked up - guilty, yer honna )

 

Where I live, FrontPage will likely still be around in 2207, never mind 2007, assuming hosting companies still support the extensions.

 

The "beauty" of it was (like any system I now now) that clients could simply dump a massive Word file on me and tell me to make a website from it - copy and paste was designed for FrontPage content :-" and for some reason Asians loved the frames page technique of static headers and sidebars - took a while for me to realise it was actually easier, leaner, and faster in css, but once I embraced and learned it, we had a ceremonial burning of the Frontpage CDs :lol:

 

I still build some sites using a raw text editor and straight html - particularly "sitelets" (to give them a nickname) simple one or two page mini-sites - useful for things like non-parked, "parked" domains, leading to a lot less faff than trying to monetise them via "Adsense for parked domains", and to a faster ramp-up time when their main script is ready.

 

A lot of people seem intent on ditching established technologies as fast as possible - if it works, why do that - e.g. I still have a standard stand-alone fax machine on the end of my desk - ever tried using scan and email for a 40-page contract that has to be signed on every page? Much easier to just slot all the pages into a real fax machine, dial, and forget until sent. (Digital signatures are still not legal in some countries, whilst strangely, faxed ones are legal - go figure.)

 

Horses for courses I guess. My current contracts list is way too overloaded for me to faff around learning 960 and jscript-UI ( hope that fits the pedants' expectations :P .... thinks I might start calling it Philscript-ME :lol: ) - with my current workload, it'll be Christmas next year before I have time for it - Hey! maybe we'll have osC 3.x by then, and I can do a double-learning session?

[totalnumpty]

So, after all that ....

 

When are we going to see an official and final osC v2.3 linked on the osC.com downloads page?

 

:-"

[Harald Ponce de Leon]

Hi Gaz..

 

When are we going to see an official and final osC v2.3 linked on the osC.com downloads page?

 

Soon. In addition to addressing the bug reports (big thanks to those helping out!), we're making HTML to XHTML updates and testing a multiple product images feature.

 

Kind regards,

[spoofy]

Hi Gaz..

 

 

 

Soon. In addition to addressing the bug reports (big thanks to those helping out!), we're making HTML to XHTML updates and testing a multiple product images feature.

 

Kind regards,

 

 

Thanks for the update Herald.

[totalnumpty]

Hi Gaz..

 

 

 

Soon. In addition to addressing the bug reports (big thanks to those helping out!), we're making HTML to XHTML updates and testing a multiple product images feature.

 

Kind regards,

 

Thanks Harald, though quantification of "soon" would be really nice - soon this year, or soon this century?

 

Now, those changes, I DO agree with .... (snigger - that'll keep the girls busy stripping the image links from descriptions and moving them to the extra product fields - why should I have all the fun?).

 

Got to ask though - the sudden rush of new inbuilt features - is that by any chance a policy to stop people whining about lack of core upgrading? Seems mighty odd to have a surge in new features right before final release.

 

Gaz

 

 

Edit : Rats! - forgot to ask .... any chance, any chance at all, of having something like the product extra fields / extra product fields contribs built in, but focussed solely at Google's product attributes - it would make a mega difference in search results, and give osC a huge leg-up on the competition in that context.

[MrPhil]

OK - I won't call you Phillip - is Philip OK?

Nope. I do not answer to either spelling of Phillip/Philip.

[spoofy]

Edit : Rats! - forgot to ask .... any chance, any chance at all, of having something like the product extra fields / extra product fields contribs built in, but focussed solely at Google's product attributes - it would make a mega difference in search results, and give osC a huge leg-up on the competition in that context.

Can you be more specific about google's product attributes?

[Harald Ponce de Leon]

Hi Gaz..

 

Got to ask though - the sudden rush of new inbuilt features - is that by any chance a policy to stop people whining about lack of core upgrading? Seems mighty odd to have a surge in new features right before final release.

 

Our focus is to bring osCommerce forward with the new v3.0 framework, not with v2.x release updates. We are fortunate to have a trusting and strong community providing new features for v2.x as add-ons.

 

Edit : Rats! - forgot to ask .... any chance, any chance at all, of having something like the product extra fields / extra product fields contribs built in, but focussed solely at Google's product attributes - it would make a mega difference in search results, and give osC a huge leg-up on the competition in that context.

 

Not for v2.3 - perhaps in the v3.x series though.

 

Kind regards,

[Ken44]

@ MRPhil

 

Hi Phil

 

I don’t fully understand MySQL but I have implemented the JOIN operator changes suggested here

 

http://www.oscommerce.com/forums/topic/335136-osc-and-mysql-5-1054-errors/

 

I noticed that these changes do not appear to be implemented into osCv2.3

Are these changes required? Please submit a bug report if they are.

 

Regards

 

Ken

[panicgripdesigns]

All the javascript code should go in head unless the code has to read/write or alter something within the body.

 

Apart from validation and correct usage, the code loaded in the <head> tag loads before the page is loaded and ready before it loads.

 

I can't say I agree with that.

 

If a piece of javascript is located externally, such as the Google Analytics Urchin, I tend to place it at the bottom of the page, so that it loads after the rest of my page has loaded, and if the site where it is hosted is down, it does not take my site down with it.

[totalnumpty]

Can you be more specific about google's product attributes?

 

 

For UK Product feeds = http://www.google.com/support/merchants/bin/answer.py?answer=188494&hl=en_GB'>http://www.google.com/support/merchants/bin/answer.py?answer=188494&hl=en_GB

 

For US Product Feeds = http://www.google.com/support/merchants/bin/answer.py?answer=188494

 

Index for other countries = http://www.google.com/support/merchants/bin/answer.py?hl=en&answer=171375

 

You can see there's a lot of overlap in the field names and allowed content (data type) - having the "common" fields and data-types built in to osC would mean better placement per product within natural search, and far higher placement within Google Shopping Search if the various feed contribs were to take account of those fields. Even if they didn't natively, from what I've seen examining them, it would be a relatively simple job to expand the captured and submitted fields within the feed contrib code.

 

The main enacting question would be whether it was better to add yet another table to the osC database to hold those Google attributes independent of the main products and attributes tables, or to modify the existing tables - personally I'd probably go for adding another table and use the existing product ID as the cross link index key - that way it avoids table overwriting if there's a future upgrade path to core.

 

Considering all the major 3rd-party marketplaces (from Amazon through Zazzle) have been implementing this (progressively) over the last 3-4 years, I'm really surprised the osC Dev community hasn't caught on to it.

 

A further thought here is that having this in place in core, would allow expansion via contrib or module to turn a fairly stock osC store into a multi-marketplace inventory management system, with dynamic allocation and submission of inventory to those 3rd-party marketplaces. In that respect too, osC is being left standing by some of the other store systems (including hosted service sites such as eBay's own ProStores, and independents like Auctiva stores, EKM, and so on). Even the "new" marketplaces like Bonanza/Bonanzle, eBid, Etsy, and others, have developed APIs for submission via 3rd party feeds/tools.

 

The days of having all your stock on a single site (your own or a 3rd-party) were killed off in 2006 when eBay's policy changes forced millions of sellers to go multi-channel - a movement that has progressively gained momentum, and is why you now find household name corporates listing on the 3rd party marketplaces, and in sites like Craigslist, facebook classifieds, as well as eBay and all the others, plus the growth in "private" shopping venues where big name brands run exclusive offers for those sites' members.

 

osCommerce could be a real driver for small and medium vendors to spread their inventory if it first has the data fields in core to populate the search engines' requirements, and then has the output tools to feed inventory to a broad spectrum of 3rd-party sites. "Magoo", Zen, and the others don't have that yet - osC can really steal a march on them if its planned and implemented early. The Froogle etc feeders that are in contribs now, are really only the toe-in-the-water on that sort of channel spreading. Sadly, even the savvy store owners are having to do manually, that which osC would be perfect for dynamically managing.

 

An example and simple scenario - an item has been in osC store for months and not sold. click the button to open a page to submit it to eBay "on special", edit what's needed, click - it gets submitted to eBay (or wherever) and the API pulls back the URL it'll appear under, and the time it ends on the 3rd-party site. The in osC product page is updated to include a "nofollow" link, button, or whatever, to where it is on the other site (or the add-to-cart button's link is temporarily changed). Meanwhile, knowing eBay listing fees can get expensive, the site admin queues up some other sites to send it to if the eBay listing doesn't sell. It ends on eBay unsold, the API confirms this, deletes it from the seller's eBay unsold items list, and squirts it at eBid or Etsy (wherever) for free listing there for a period. OMG - it's still unsold ... OK, let's try somewhere else and maybe trim the price a little, and some of the keywords and title, then queue another list of sites to rotate it through.

 

While all of this is happening, the item is still visible in the osC store, highly indexed in the search engines, and depending on API capability, can be cancelled auto-magically on the 3rd party site if bought in osC, or the buyer in osC bounced to the 3rd party site to buy there - buyers could even be given the choice of which they prefer.

 

Now I know a lot (if not all) of that is contrib territory, not core, but it all starts with having the Google (et al) product attributes in core product-data for normal feed submissions to the search engines. Despite all the hooha and whining about eBay's changes to "product specifics" and how they used them to remove all the browsable sub-categories, if you look dispassionately at them, eBay's product specifics broadly match Google's product attributes - so if even haughty eBay can be dragged into the Google method, then surely osC should embrace it voluntarily?

 

phew - tired fingers, breakfast's just arrived, so I'll pause there.

[totalnumpty]

Thanks for the answers Harald - I'll not disguise disappointment at lack of product specifics/attributes in 2.3 (or even a 2.4 if one emerges), but I do understand manpower constraints.

[totalnumpty]

I can't say I agree with that.

 

If a piece of javascript is located externally, such as the Google Analytics Urchin, I tend to place it at the bottom of the page, so that it loads after the rest of my page has loaded, and if the site where it is hosted is down, it does not take my site down with it.

 

:thumbsup:

[spoofy]

For UK Product feeds = http://www.google.com/support/merchants/bin/answer.py?answer=188494&hl=en_GB'>http://www.google.com/support/merchants/bin/answer.py?answer=188494&hl=en_GB

 

For US Product Feeds = http://www.google.com/support/merchants/bin/answer.py?answer=188494

 

Now I know a lot (if not all) of that is contrib territory, not core, but it all starts with having the Google (et al) product attributes in core product-data for normal feed submissions to the search engines. Despite all the hooha and whining about eBay's changes to "product specifics" and how they used them to remove all the browsable sub-categories, if you look dispassionately at them, eBay's product specifics broadly match Google's product attributes - so if even haughty eBay can be dragged into the Google method, then surely osC should embrace it voluntarily?

 

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..

[burt]

Sorry I disagree with that.

 

 

You are disagreeing that I found someone else who thinks as I do ? Hmmmmm.

 

Anyway, nothing wrong with 960gs if that floats your boat.

 

Some designers don't want/need it. Some do.

[Mark Evans]

Some designers don't want/need it. Some do.

 

 

I personally quite like 960 and I also like some of the other css frameworks out there as well. I don't think we will ever find something that everyone is happy with but I think just the sheer improvements being made by moving to CSS will mean developers/designers will get more flexibility.

 

The other interesting thing for me is that this can help us during the v3 development cycle as 2.3 will give us invaluable feedback on how people will use it

 

 

[burt]

I agree - but the point is that a css layout should give the designer 100% flexibility to do precisely as he/she wishes in order to achieve the desired effect. I have not seen a single site using the 960 system where I thought "wow, cool". They all look homogenised. Have you (or anyone else) seen any that really stand out in terms of LAYOUT.

[burt]

So, do designers use it?

 

<div class="grid_6"></div>
<div class="grid_6"></div>

 

Fair enough, for a very simplistic example (assuming container_12 for the wrapper) ? 2 halfs of the page. Easy right?

 

Try adding a 10 pixel border to just the first one. What happens?

 

Oh. Errrr.

 

.grid_6 {
  border: 10px solid black;
}

 

Oh. They both have borders. Hang on, easy change;

 

<div class="grid_6 bordered"></div>
<div class="grid_6"></div>

 

.bordered {
  border: 10px solid black;
}

 

Phew. That's better. Refresh the page. Oh. Errrr.

 

Now my overall design is farked as I'm 20 pixels too wide. Start over.

 

As I said, a very simplistic example (try use padding or margin instead of [or as well as] border) - which goes some way to demonstrating the INflexibility of a frameworked system.

 

Of course, I may just be spouting rubbish in the opinion of some people ;)

[burt]

In imagery, for those who can understand images better;

 

Half and half divs, with an extra class each to differentiate them;

 

 

And in the stylesheet;

 

 

Fair enough? Makes this:

 

 

If I now add the border to the PINK div only;

 

 

Look what happens;

 

 

This is not ideal. I realise that in "real life" a designer won't add an ugly 10px border ;)

[sammysumer]

You are right burt

 

960 grid is a very poor choice.

 

However YUI 3 grid system gives designers complete flexibility in layout. You don't have to rely on preset width or height. You can style it however you like.

 

Or no grids at all and let us design however we want it. but I don't thinks osC 2 series is flexible enough to do that. May osC 3.0 will give us that flexibiliy.

 

Look at Joomla! templating system. It is state of the art. You can style your site however you like. Those who have worked with Joomla! know what I mean.

 

Please don't give us 960 grid in osC 3.0