OsCommerce v 2.3 - when?

spoofy · October 25, 2010

Also, I noticed that the message stacks for the different pages do not have a "consistency".

I recommend using the Highlight and Error boxes which are included in the jquery ui

Mark Evans · October 25, 2010

Looks like I have a good number of new issues to fix... thanks for everyone who has spent time bug searching, it all helps to make 2.3 as stable a release as possible

totalnumpty · October 26, 2010

Ideally, simply from the point of code cleanliness, all JS function definitions and global initializations should be up in the <head> section. Only "in-line" (immediately executable) code (as well as "on___" tag attributes) should be in the <body>. If you use a common "top of page" code to create the <head> section, you need a way to insert different JS code for different pages, rather than including everything on every page (see @spoofy's suggestion).

From a user experience point of view, all the javascript should be in the footer not the head - you can create and use an "enqueue" function to list the head placement scripts needed, but then actually have the code in the footer - that way all the rest of the page loads before the javascript is run, resulting in the user having "something" on screen to look at while the javascript loads and processes.

It's a method used by a lot of scripts nowadays (including WordPress) and it does not invalidate XHTML

A further benefit of going that route is you can create self contained footer files for each area of the site running different javascripts, or use an extension of the OptionalHeaderTags idea using something like OptionalFooterTags - of course, you then might be increasing your http calls and introducing server load and pageload overhead.

Worth thinking about though?

(edit - typos)

totalnumpty · October 26, 2010

The javascript for the V2.3 buttons are also causing some conflicts with things like "fancypics" popups.

I don't understand why java is being used for the buttons anyway - anything you do to them in java, you can now do 100% with pure css - including all the rounding, glossy-aqua styling etc, using a heap less server resources and a far faster load time.

For people using dino-browsers, you just use a fallback image via the css and browser specific stylesheet optioning.

spoofy · October 26, 2010

I don't understand why java is being used for the buttons anyway - anything you do to them in java, you can now do 100% with pure css - including all the rounding, glossy-aqua styling etc, using a heap less server resources and a far faster load time.

For people using dino-browsers, you just use a fallback image via the css and browser specific stylesheet optioning.

It's being done via Jquery-ui

spoofy · October 26, 2010

From a user experience point of view, all the javascript should be in the footer not the head - you can create and use an "enqueue" function to list the head placement scripts needed, but then actually have the code in the footer - that way all the rest of the page loads before the javascript is run, resulting in the user having "something" on screen to look at while the javascript loads and processes.

It's a method used by a lot of scripts nowadays (including WordPress) and it does not invalidate XHTML

A further benefit of going that route is you can create self contained footer files for each area of the site running different javascripts, or use an extension of the OptionalHeaderTags idea using something like OptionalFooterTags - of course, you then might be increasing your http calls and introducing server load and pageload overhead.

Worth thinking about though?

(edit - typos)

Any code which resides in <head> tag is made available before the page is completely loaded. Thus the name "head". The idea that the user would benefit from looking at a page while it loads and re-corrects everything after the javascript has completely loaded is a disaster.

As of right now the entire styling is controlled by jquery-ui. What you are saying is that let the ugly page load until the jquery-ui kicks in. Sorry I disagree.

totalnumpty · October 26, 2010

And what I rebut with is that by introducing a programming language that very few people understand is an open invitation for hackers to bury their crap in locations that most people would not even look ... because they wouldn't know what they're looking for. It's bad enough finding it in php, even when you're familiar with the files' contents and lucky enough that the hacker used a dumb base64 encode to make it jump out at you.

No thanks - keep the flash and java for the online MMORPG players and their ilk - keep it out of my ecommerce applications.

As for the load sequencing - as I said, do it with CSS - faster, lighter on resources, and just as flexible, with a lot less chance of causing the type of server load that gets your hosting account suspended when you're running multiple domains in a single hosting account.

.... and just my tuppence worth, but ditch the 960 grid system and give designers real flexibility now that design is being split from function. Don't immediately throw a straight-jacket on them.

totalnumpty · October 26, 2010

jQuery UI provides abstractions for low-level interaction and animation, advanced effects and high-level, themeable widgets, built on top of the jQuery JavaScript Library, that you can use to build highly interactive web applications.

- - - http://jqueryui.com/

You could tell my site to pull the Pentagon's most secret spies roster in javascript, and to send it to the Kremlin, and I wouldn't have the faintest idea what it was up to. I barely manage to keep up to date with all the changes and advances in html, css, and php, without having to add yet another compiled language into the mix.

Nope - absolutely not wanted on my sites.

Edit - try it this way instead - http://girliemac.com/blog/2009/04/30/css3-gradients-no-image-aqua-button/

Edit2 - even better - try this way as well - http://www.schillmania.com/content/entries/2009/css3-and-the-future/ (see bottom of page for really good examples - hover mouse on them).

npn2531 · October 26, 2010

Putting javascript in the footer is often, but not always, a good idea. Like you point out, since the page html loads first, it appears to the user that the page is fully loaded while the javascript loads in the 'background'. However, if the javascript is used to control how the html displays, say in a navigation bar or a sliding panel, then you want the javascript in the header, or the page is going to go through major visual 'shifting' in the process of loading.

Why you would use javascript for buttons? I'm struggling to find a reason. For a navigation bar, however, yes it works fine and faster in pure CSS. But slowing down the CSS is the point of using javascript in a navigation bar. Drill down several levels in a pure CSS drop down, and then let your mouse waver just a bit and you have to start over. JS gives you a few hundred milli seconds to waver back with out the navigation tree collapsing.

npn2531 · October 26, 2010

The 960 grid is limiting, but not as much as you may think. For example, you can go into the single stylesheet that has the 960gs grid calculations, make changes on the grid widths and convert it to say a 1080px width website. You can even change the grid widths to percentages and have a website that expands to fit the browser window. It's not rocket science, just patience and a calculator. But you only have to do it once.

The point of the grid is to create proportional consistency to enhance design and text readability. In that sense a limiting structure is desirable and can greatly cut down on web development time.

burt · October 26, 2010

ditch the 960 grid system and give designers real flexibility now that design is being split from function. Don't immediately throw a straight-jacket on them.

Someone else understands! I'm not alone!! Yippee lol

npn2531 · October 26, 2010

If you don't want to use the 960gs system, you can get rid of it. All you have to do is delete the file ext/960gs/960_24_col.css. Then add these selectors to stylesheet.css and give them your desired width :

.container_24{}
.grid_24{}
.grid_16{}
.grid_4{}

grid_4 is the column width, grid_16 is the body width and grid_24 is the body width. You'll also need to make a couple of simple changes in template_top and template_bottom, like move column_left to template_top. But that's all. No more 960gs grid.

Collines · October 26, 2010

I would imagine that most people would prefer a system that makes creating their site as easy as possible.

Those that want more control can easily remove the grid system.

As long as tables are used for tabular data and not layout, anything will be a massive improvement.

BlackGoggles · October 26, 2010

ditch the 960 grid system and give designers real flexibility now that design is being split from function. Don't immediately throw a straight-jacket on them.

I really can't understand what the kerfuffle is about integrating the 960 gird system. Surely as a "designer" the 960 grid system would be used to rapidly prototype your skeleton design with a view to code your own CSS markup once this is achieved? What the team have done is take a massive amount of development time "off our shoulders" by removing the tabular HTML and presenting us with <div><span>'s, a much more design flexible structure. I've already removed the 960gs from my local machine after spending 30 minutes using it to prototype my "skeleton" page. The whole process will not take more than 1.5 hours to have a completely bespoke site! So as a "designer" I would whole heartedly stick with this as a base structure. Think of osCommerce as a framework to build upon, not a complete store, especially if you are using this a method to generate income! For those who can't 'code', v2.3 is a HUGE leap forward.

The above principles can be applied to the use of jQuery UI.

What people should be concentrating their efforts on is improving the "fixed" bug count (finding them in the first instance), help achieve a validated HTML markup and zero PHP errors.

Reason for edit: typos

npn2531 · October 26, 2010

actually grid_16 would be the content width, grid_24 would be the header and footer width and container_24 the 'body' width.

MrPhil · October 26, 2010

I don't understand why java is being used for the buttons anyway - anything you do to them in java, you can now do 100% with pure css - including all the rounding, glossy-aqua styling etc, using a heap less server resources and a far faster load time.

For people using dino-browsers, you just use a fallback image via the css and browser specific stylesheet optioning.

Uh, you'd be a lot more credible if you stopped confusing Java and Javascript. They're completely different things -- different languages, running in different places, doing different things.

spoofy · October 26, 2010

jQuery UI provides abstractions for low-level interaction and animation, advanced effects and high-level, themeable widgets, built on top of the jQuery JavaScript Library, that you can use to build highly interactive web applications.

- - - http://jqueryui.com/

I don't think you know what jQuery is do you? Sorry I am not trying to be personal but that is a baseless argument. Every major e-commerce site now a days has 2 common features:

1) Mouse over image zoom

2) Quick view from product listing page

How do you think they accomplish that? via css!? no sir! all done via javscript. A good handful large ecommerce sites do use jquery to do this.

And what I rebut with is that by introducing a programming language that very few people understand is an open invitation for hackers to bury their crap in locations that most people would not even look ... because they wouldn't know what they're looking for. It's bad enough finding it in php, even when you're familiar with the files' contents and lucky enough that the hacker used a dumb base64 encode to make it jump out at you.

No thanks - keep the flash and java for the online MMORPG players and their ilk - keep it out of my ecommerce applications.

As for the load sequencing - as I said, do it with CSS - faster, lighter on resources, and just as flexible, with a lot less chance of causing the type of server load that gets your hosting account suspended when you're running multiple domains in a single hosting account.

.... and just my tuppence worth, but ditch the 960 grid system and give designers real flexibility now that design is being split from function. Don't immediately throw a straight-jacket on them.

I really think you should spend some time and learn what oscommerce really is about. The system has always been very VERY flexible. You want those CSS buttons instead of jquery-ui buttons.

Just go in and change tep_draw_button

Please spend some quality time understanding the code then come back here with some arguments. Also, let's not talk about loading and hosting issues. That's all personal preference anyway. If you are running a decent ecommerce site, then you shouldn't be using shared server. Meaning you should be using a VPS or dedicated which should be optimized for your e-commerce site. You want to know what resource hog is? Try Magento and then come back.

spoofy · October 26, 2010

Someone else understands! I'm not alone!! Yippee lol

Sorry I disagree with that. Since I have spent the last few days completely re-doing the design, I can tell you that it has been a piece of cake work!

Grid960 maybe limiting for some designers but the way it has been implemented in oscommerce is not limiting. See below:

If you don't want to use the 960gs system, you can get rid of it. All you have to do is delete the file ext/960gs/960_24_col.css. Then add these selectors to stylesheet.css and give them your desired width :
.container_24{}

.grid_24{}

.grid_16{}

.grid_4{}

grid_4 is the column width, grid_16 is the body width and grid_24 is the body width. You'll also need to make a couple of simple changes in template_top and template_bottom, like move column_left to template_top. But that's all. No more 960gs grid.

Thank you. You hit the nail on the head! Honestly, I dont get the fuss about using 960gs. Just as you stated that if someone wants more control on quantity of columns or width, simply use the tool on grid960 site and create a new css and viola, it's done!

I really can't understand what the kerfuffle is about integrating the 960 gird system. Surely as a "designer" the 960 grid system would be used to rapidly prototype your skeleton design with a view to code your own CSS markup once this is achieved? What the team have done is take a massive amount of development time "off our shoulders" by removing the tabular HTML and presenting us with <div><span>'s, a much more design flexible structure. I've already removed the 960gs from my local machine after spending 30 minutes using it to prototype my "skeleton" page. The whole process will not take more than 1.5 hours to have a completely bespoke site! So as a "designer" I would whole heartedly stick with this as a base structure. Think of osCommerce as a framework to build upon, not a complete store, especially if you are using this a method to generate income! For those who can't 'code', v2.3 is a HUGE leap forward.

The above principles can be applied to the use of jQuery UI.

What people should be concentrating their efforts on is improving the "fixed" bug count (finding them in the first instance), help achieve a validated HTML markup and zero PHP errors.

Reason for edit: typos

Thank you!

totalnumpty · October 26, 2010

In sequence -

@npn #159 - OK, fair call on things like nav bars that are present for every page load because they're in every header zone, and therefore it's better to load the js in the head, but how much better if the design can avoid the need for js in the first place - I'm not just talking about the visuals and layout, but also the category structuring for example. Whilst I realise some niche's may need a category structure going 194 levels deep, most stores are likely to rarely exceed 4 or 5, and that can be planned into the layout design.

They're no longer the best example on the web, but look at how eBay controls the category depth & width visibility depending on how deep you are into the site - just one pointer being that the full (flat) list of top level cats are never more than a mouse point or click away, leaving the current page to focus on the navigation within the category being displayed. They also make extensive use of product parameters to improve navigation - in a similar way that topic tags work on a WordPress blog, but with strictures per category in the same way that Google has a pre-defined list of attributes that can be added to products (AND WHICH osC HAS STILL NOT BUILT IN :angry: ) - tag clouds or attribute clouds come to mind here as a way to remove an entire nav-bar structure and replace it with dynamic contextual data, and a smaller on-screen pixel footprint.

@npn #160 - Sorry, not buying that. What the 960 grid system is doing is placing everyone in layout kindergarten - I don't want my vertical alignments constrained to 48-pixel wide columns ( 960 / 24 = 48 ) especially if I want to run a 120 or 125 wide column of buttons, ads, text links, or whatever. Similarly, I don't want my horizontal zones constricted in a similar way causing the zone outlines to be as regimented as a chessboard. Whilst chequerboard layouts do suit data as ordered as an online store, they do lead to a large amount of "sameness" that becomes as bad as the current tables and cells layout ..... You ready for an Oriental Zen moment? Look at a tree, really look at it. Think about it as an element formatting model, with the leaves as products and info pages, the branches as category paths and shopping basket, the trunk as final checkout. Now look at it as a design presentation - it's fixed yet fluid, rigid yet flexible, ever growing, yet constrained. (Wierdo moment alert) Be a tree in your designing, not a sheet of graph paper.

@burt #161 (see my last paragraph)

@npn #162 - - - YUCH! .container_which? .grid_what? Quit the obfuscation - if it's a wrapper div, call it .wrapper - if it's the content div, call it .content - if it's the left sidebar, call it .sidebarleft - stop fogging and hiding the simplicity of css, that's why so many newbies get into trouble with it. The intrinsic power of css is the complete openness and flexibility of the object labelling for divs, spans, IDs and so forth - don't chain it up and force a non-intuitive naming convention on it. Any such stricture should be on a "cheat-sheet" quick guide only, not active in the wild.

@Collines #163 - if they want it as easy as possible, then they will have to wait until osC v3.x arrives with a full fledged drop-in theme and template system similar to WordPress's, and then wait a year or more for a central theme repository to fill up with sufficient choice to allow differences between stores, and then some more time for osC theme designers to catch up with WordPress theme designers in terms of adding admin-configurable options such as user-selected colour schemes, background and header image customisation and so forth, plus of course all the widgets, and data manipulation / presentation tools and so forth.

If they want it as easy as possible, some would say they shouldn't be running either a website, or a business, because neither is "easy" and just when you think it is, the hackers and spammers strike - hmmm?

@BlackGoggles #164 - Two thoughts spring up here - 90 minutes for a bespoke site? Maybe if using only a stock osC, but the moment you start adding contribs, then you have additional input/output elements to place on screen - Google attributes for example, or product options, shipping options and so forth - 90 minutes becomes a dream at that point. Cross-script integrations (e.g. with a blog or user forum, or a news aggregator) also blow that out of the window. There's also conditional elements to think about coding. Nope, not seen 90 minute site design since way back when the web was AOL, Compuserve, and Netscape Navigator text-only output, and don't believe it will ever return to those time-frames again.

On the other hand, 90 minute skeleton theming - yup, I'll hope for that, it'll open a whole new osC-related industry for theme designers, and I'll merrily embrace that (it fits with some of my plans for next year). I'll give it a go, but right now, I'm not convinced.

@npn #165 - again, why not call them what they are? Your example of grid_24 for example, depending on the z-align value could have several or dozens of grid_24's on a single page - no-repeat background images for different positions, but they need unique names for the divs to easily identify them in the code and the stylesheet. Having an array or cascade of "grid_24" would be almost as eye-boggling as the current table system.

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

All in all, what I'm seeing here, with 960, is a diversion from learning semantic mark-up - a stock osC (in fact any web page) has several base structural elements that newbies are going to struggle to learn about by having 960 blindfold them to correct structuring - examples being - page, wrapper, background, container, header, sidebar-left, content, sidebar-right, footer, sidebox, content-box and so forth (it'll vary by site and designer, but it's a fairly standard nomenclature list). Coding those raw onto a stylesheet gives a better understanding of where they fit together - one of the biggest stagnators for my own learning curve was when I discovered Microsoft Frontpage about 12-15 years ago. It took me until 2007 to shake that off and get my fingernails dirty in real code. I worry we may be introducing a similar issue here, to newbies, by adopting 960 into the osC core package.

Mark Evans · October 26, 2010

You could tell my site to pull the Pentagon's most secret spies roster in javascript, and to send it to the Kremlin, and I wouldn't have the faintest idea what it was up to.

You might want to take a look into just how the javascript security model works

I barely manage to keep up to date with all the changes and advances in html, css, and php, without having to add yet another compiled language into the mix.

Just because you don't want to keep up to date and understand what things it can do, doesn't mean we should hold others back that do. You might also want to check your reference to javascript being a compiled language

totalnumpty · October 26, 2010

I don't think you know what jQuery is do you? Sorry I am not trying to be personal but that is a baseless argument. Every major e-commerce site now a days has 2 common features:

1) Mouse over image zoom

2) Quick view from product listing page

How do you think they accomplish that? via css!? no sir! all done via javscript. A good handful large ecommerce sites do use jquery to do this.

Ever heard of the concept of dynamic style sheets? putting the style sheet inside a php file instead of a css file, and using the standard commands "onhover" and "onclick" - use those and you don't need javascript. Admittedly you'll need to include a "close" button in the popup window, but people are used to that.

I really think you should spend some time and learn what oscommerce really is about. The system has always been very VERY flexible. You want those CSS buttons instead of jquery-ui buttons.

Just go in and change tep_draw_button

Now that IS being just plain insulting. I could do the "childish forum user" thing and point at the difference in our joining dates for this forum, or I could do "the petulant thing" and reel off how many websites and web-farms I have, and how many hosts and hosting types I use, or, worse still, layout my CV and waffle about how "Tim Berners Lee was still a lad when I started in IT" ..... instead I'll just repeat what my grandmother taught me - "making assumptions about people you don't know is always a stupid game to play".

Please spend some quality time understanding the code then come back here with some arguments. Also, let's not talk about loading and hosting issues. That's all personal preference anyway. If you are running a decent ecommerce site, then you shouldn't be using shared server. Meaning you should be using a VPS or dedicated which should be optimized for your e-commerce site. You want to know what resource hog is? Try Magento and then come back.

Now you're showing your own assumptions and attitudinal-ignorance - page-load time is not solely about the code and the hosting type - you also have to think of your user's connection method, and distance from server. And, just in case you've missed such things, you also have to think about the laws of various nations, their "cyber-cops" and the censorship and content inspection and interception they operate - all of which slows down load times, and depending on your target market, can have huge impacts on sites bloated with javascript-loading and so forth.

Not everyone has a 100GB fibre connection, some countries (outside of national capitals) are still fairly restricted in connnection speeds and infrastructure. Large parts of the world do still use 33,600bps dial-up modems because that's all their national telco's will allow them to use, or all they can afford as users. The trick as site designers is to cater for those with the mainstream connection type, without alienating or cutting off those with less bandwidth. Anything you do to improve the user experience of those on slow connections will benefit those on faster ones too.

Final thought - and think about it carefully - ever noticed how bank and post office queues got noticeably slower at about the time those businesses began using GUI-based cashier terminals? There is no way the mouse can match the speed of a set of fingers that know the keyboard shortcuts, and the processor will always respond faster to straight text input/output than when it has to render graphics (animated or not). Don't be a Microsoft - don't turn a 3-FDD operating system into a boxed set of HD-DVD's to install it. Keep osC core light, clean, and lean.

npn2531 · October 26, 2010

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?

totalnumpty · October 26, 2010

You might also want to check your reference to javascript being a compiled language

Pedant!! :angry:

:-"

You know what I meant - don't allow your assumed greater knowledge to turn into arrogance.

npn2531 · October 26, 2010

Gaz,

I will admit, I was not thinking about the 'laws of various nations' when I embraced the use of javascript.

But sweet jeebus, you used Frontpage for a decade? Was it still around in 2007?

spoofy · October 26, 2010

Ever heard of the concept of dynamic style sheets? putting the style sheet inside a php file instead of a css file, and using the standard commands "onhover" and "onclick" - use those and you don't need javascript. Admittedly you'll need to include a "close" button in the popup window, but people are used to that.

Now that IS being just plain insulting. I could do the "childish forum user" thing and point at the difference in our joining dates for this forum, or I could do "the petulant thing" and reel off how many websites and web-farms I have, and how many hosts and hosting types I use, or, worse still, layout my CV and waffle about how "Tim Berners Lee was still a lad when I started in IT" ..... instead I'll just repeat what my grandmother taught me - "making assumptions about people you don't know is always a stupid game to play".

Now you're showing your own assumptions and attitudinal-ignorance - page-load time is not solely about the code and the hosting type - you also have to think of your user's connection method, and distance from server. And, just in case you've missed such things, you also have to think about the laws of various nations, their "cyber-cops" and the censorship and content inspection and interception they operate - all of which slows down load times, and depending on your target market, can have huge impacts on sites bloated with javascript-loading and so forth.

Not everyone has a 100GB fibre connection, some countries (outside of national capitals) are still fairly restricted in connnection speeds and infrastructure. Large parts of the world do still use 33,600bps dial-up modems because that's all their national telco's will allow them to use, or all they can afford as users. The trick as site designers is to cater for those with the mainstream connection type, without alienating or cutting off those with less bandwidth. Anything you do to improve the user experience of those on slow connections will benefit those on faster ones too.

Final thought - and think about it carefully - ever noticed how bank and post office queues got noticeably slower at about the time those businesses began using GUI-based cashier terminals? There is no way the mouse can match the speed of a set of fingers that know the keyboard shortcuts, and the processor will always respond faster to straight text input/output than when it has to render graphics (animated or not). Don't be a Microsoft - don't turn a 3-FDD operating system into a boxed set of HD-DVD's to install it. Keep osC core light, clean, and lean.

You are right. I am wrong. Let's move on :)

OsCommerce v 2.3 - when?

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Archived