Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

What is the biggest default / less of Oscommerce


Gyakutsuki

Recommended Posts

This topic has goal to evaluate where is the biggest default : ergonomie of oscommerce.

No to speak for example osc is not B2B, just focus on the original version / features who must be better

 

For me :

attributes is not perfect and must be upgraded via a variant product for example

categories/products in the same files : must be separated for best management

 

 


Regards
-----------------------------------------
Loïc

Contact me by skype for business
Contact me @gyakutsuki for an answer on the forum

 

Link to comment
Share on other sites

internationalization eg /en-us/ vs /en-gb/ driving both language and shipping defaults.

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

For me its stock control on attributes. Current addons alter so much core code they really go against where oscommerce wants to head.

 

Some of the back end reporting could be better, but that might/ought to change in the next version. If the back end becomes as modular as the front end it will be easy, once developers start producing the code, or shop owners want features and they get released as addons. Everything just needs improving and made fit for purpose for the year 2016.

 

I do think oscommerce has got the one page category/product addition dead right. As soon as more pages are added, it makes things more complicated, which means more mistakes. Keep it simple, us store owners love that.

REMEMBER BACKUP, BACKUP AND BACKUP

Link to comment
Share on other sites

Discount coupons should be in core code.

 

Should have the ability to easily install skins or templates which change the whole look of the shop.

 

Newsletter functionality is useless and should be replaced or removed.

 

HTML emails should be core code.

 

Automatic updates are needed (this is coming according to this post)

 

An addon marketplace where addons and developers are rated by the community, with the ability for addon creators to charge for their addons.

 

Automatic updates for addons (this also appears to be a feature in 2.4).

osCommerce user since 2003! :thumbsup:

Link to comment
Share on other sites

internationalization eg /en-us/ vs /en-gb/ driving both language and shipping defaults.

 

+1 Language handling is the biggest fault on oscommerce. But not only that. Oscommmerce does not even store the language an order was placed so it's impossible to handle any automated communication out of the box.

Many things relies on data stored as localized strings instead of ids. Even options and values for attributes are stored as localized names - impossible to work with!!!

 

Other missing things for me are:

  • A basic URL rewritter that at least makes different the URL for each language -> no SEO dupes.
  • The ability of editing order details (like a wrong typed address or telephone or addition/removal of products) is a need IMO.
  • Attributes are not very useful without a reliable stock control. And have you tried the stock attribute creation page??? It must have been there untouched and unfinished from the beginning, I suspect.
  • HTML emails.

Almost everything else I can imagine could be added as addons.

Link to comment
Share on other sites

Since v2.3.4 BS, the support of Bootstrap offers more alternative to adapt the catalog form but the admin was not thought to be optimized.

The products attributes is a weak point that could be solved by adding QT Pro (the latest version with QTPro Doctor feature is a great improvement) but to manage the attributes from the edit page of the product would be less complicated admittedly.

The "Master" version of v2.3.4 BS comes with SEO built-in but too limited compared to the current Header Tags SEO module...
I had to replace everything to get something worthwhile...

Here are all the usefull addons (that I have already installed) that will improve the script :
- 03. Ultimate_SEO_URLSv22d_14
- 04. HeaderTags_SEO_V_3.3.4
- 05. qtpro 4.6.1
- 06. price break per quantity (adapted from my old v2.2)
- 07. Attribute_Weight v0.3
- 08. tvaintracom_v5.1 + IP recorder
- 09. edit order
- 10. create order
- 11. Horizontal Categories Menu BS
- 11.1 Categories Menu XS_ver1.0
- 12. store_search_bar_1.2
- 14. Display Cart After Adding Product
- 17. newsdesk (adapted from my old v2.2)
- 28. manufacturer dropdown everywhere
- 36. visitor stats
- 40. Margin Report 2.3.4
- 44. ckeditor (adapted for categories.php and newsdesk.php)
- 51. frontpage caroussel
- 60. back_to_top
- 69. Country_State_BS_2_4_1

 

There is so much to add to get a nice result that it can be unfortunately demotivating for some pepole...
The back office is in my opinion the biggest downside of oscommerce.

Osc v2.3.4 BS "custom"
PHP 7.3 compatible (710 modified files => o_O')

Link to comment
Share on other sites

@@milerwan

 

Its no use listing addons that you use in your store, they will never be added. Whilst a lot of what you mentioned would be good, and would bring oscommerce up to date and be fit for purpose, the chances are it will not happen.

 

As long as addons exist and someone somewhere is prepared to update them, then that is what will happen. If every shop owner that used an addon and had to alter it for a particular version uploaded the files to the addons area, addons would improve.

 

If you dont like what oscommerce offers there are many alternatives if you want them.

REMEMBER BACKUP, BACKUP AND BACKUP

Link to comment
Share on other sites

@@milerwan

 

Its no use listing addons that you use in your store, they will never be added. Whilst a lot of what you mentioned would be good, and would bring oscommerce up to date and be fit for purpose, the chances are it will not happen.

 

As long as addons exist and someone somewhere is prepared to update them, then that is what will happen. If every shop owner that used an addon and had to alter it for a particular version uploaded the files to the addons area, addons would improve.

 

If you dont like what oscommerce offers there are many alternatives if you want them.

 

Sorry but why then ask what is the default Oscommerce in this case ?

Those who call the defaults would like to see changes, and if you would like to see something changing, you don't like Oscommerce?!?
Curious thinking.

 

If I did not like oscommerce, I will not have redone my site with and will not respond to this threat too...  :- 

 

The answers are in the addons, it's the basic tenet of osCommerce.

 

Osc v2.3.4 BS "custom"
PHP 7.3 compatible (710 modified files => o_O')

Link to comment
Share on other sites

The answer may be in the addons, but they will never be added to the core. This argument has been done and keeps getting done. It just wont happen.

 

All we can hope is that the latest version does include some new code which will give shop owners what they want in 2016. Only Harold knows what he has planned, so we just have to wait.

REMEMBER BACKUP, BACKUP AND BACKUP

Link to comment
Share on other sites

@@milerwan

please understand that some things are serious limitations of oscommerce that cannot be solved by adding on code, they would need to change core oscommerce files.

The whole idea going forward is to have oscommerce more modular, so you can easily add bits and pieces, but it still requires a solid ecommerce core to allow that.

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

Sorry but why then ask what is the default Oscommerce in this case ?

Those who call the defaults would like to see changes, and if you would like to see something changing, you don't like Oscommerce?!?
Curious thinking.

 

If I did not like oscommerce, I will not have redone my site with and will not respond to this threat too...  :- 

 

The answers are in the addons, it's the basic tenet of osCommerce.

 

 

Easy there, easy! The idea of osCommerce is that it is a bare skeleton of a system, to which you can easily plug in additional function. Or so, that's the intent. In practice, it's never quite worked out that well. The developers are reasonable in not wanting to clutter up the base system with additional function that not everyone will want, but on the other hand, add-ons (plug-ins) and their system need to be architected to work more smoothly and not interfere with each other. WordPress seems to have gotten it pretty much right; so osC should be able to do it.

 

I would like to see osC ship with documentation spelling out preferred (suggested) add-ons that have been tested to work with each other, and many people have found useful. It would not have these functions built in; nor would they ship with the base product. There would just be clear instructions on how to obtain and install particular recommended add-ons.

Link to comment
Share on other sites

A little note for order language. Opposite to that we use it would be better to stick before the prefered language into customer registration. (There should be a hook call) The reason is practic an important case because the newsletter systems cant use customers who had no orders yet but registered.

What I and I hope @@bruyndoncx miss more that module listing not consist of module status as we could see in product listings. (This is about 10 php rows..)

Parcel shop or Pickup stores ability (I dont understand this deficiency. A lot of customers cant pickup a package in working time at home).

I agree with all of you listing above. The core should be more and more flexible to dropp on some valuable addons by a click button without core edition.

:blink:
osCommerce based shop owner with minimal design and focused on background works. When the less is more.
Email managment with tracking pixel, package managment for shipping, stock management, warehouse managment with bar code reader, parcel shops management on 3000 pickup points without local store.

Link to comment
Share on other sites

A little note for order language. Opposite to that we use it would be better to stick before the prefered language into customer registration. (There should be a hook call) The reason is practic an important case because the newsletter systems cant use customers who had no orders yet but registered.

You're right.I didn't take care of this because I wrote code to let mailchimp the current language on reguster, but it should be added to the customer account and to the order, because if you use some mechanism like purchase without account you won't have a customers language on database.

Link to comment
Share on other sites

@@Gergely

yes, i have removed the hardcoded products status from the product listings, quite some time ago so i forgot about it. i also have the same listing module reused on the different listings like in products new, specials and the regular listings.

I also have functions to return the typical modules product rows and a function to display an individual product consistently across the site. I started using a products class from @@kymation. That is another core change that would be benificial, just look at the work whitehat did with variants.

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

There are so many things that could be improved.  

 

Why not everyone pull in the same direction to move things forward/better ?

So far, I have not seen that in the last 2.5 years of trying to make forward movement.

Link to comment
Share on other sites

Why not everyone pull in the same direction to move things forward/better ?

 

 

That is the ideal, but first, we need to have some idea of what people want. See how popular some feature is, and if almost everyone would like to see it as standard, consider putting it in. If there are no proposals of things to add, and no discussion on them, how can we pull in the same direction? Granted, a more coherent system is needed to accept suggestions, weed out duplicates, get feedback, and vote on them. Then the primary developers need to consider how much in demand a feature is, how much work it is to implement into the core, whether it is likely to remain popular (how many requests for MySpace buttons do you see today?), and what risks it raises (security, maintainability, etc.).

Link to comment
Share on other sites

@@MrPhil it's a little difficult as what really needs to happen is the core to be modified to allow addons to do things without changing core (that makes sense as I think of it, not so much written down)...typical examples have already been mentioned above by Carine. 

 

Problem is - as has already been seen on this forum numerous times over the years;  

Each shopowner has their own idea of what they believe should be in core, these same people when we try to move the core forward, moan and groan that "addons no longer work", etc etc.  

 

As you can see, the life of a core developer is difficult.  Personally, I have so many ideas that could move osc forward by 10 years inside the next year, yet don't have the tools to allow me to do that.

Link to comment
Share on other sites

Burt said:

" it's a little difficult as what really needs to happen is the core to be modified to allow addons to do things without changing core"

 

That's my wish as a developer - get the core code like WordPress so that I can come along and write a little code that is going to hook into the core and 'do stuff' - no need to edit any other files, just add your own.

 

I have a secondary wish - adjust the checkout_process file so that there is a call to a payment module before_email() function. This can be used for 'pay way' modules (like PayPal) to intercept the checkout flow and redirect the user to the payment website - gets away from the rubbish code that puts the checkout_process code into the payment module itself (have a look at the PayPal Standard module)

Link to comment
Share on other sites

Each shopowner has their own idea of what they believe should be in core,

Yes, and if there was some sort of orderly discussion and voting system, we might even get a consensus on what new stuff should be in the core. I agree that we should be careful not to bloat the core with things that are not wanted by at least 90% of store owners. If a feature or add-on is that popular, it should probably be a core feature rather than something that needs to be added in separately. Some features might be built-in, but switched off by default.

 

these same people when we try to move the core forward, moan and groan that "addons no longer work", etc etc.

I think this is going to be a perpetual problem, no matter how well written an add-on is. Eventually, the underlying core code may change enough to break some add-ons. How about this: a formal "adopt-an-add-on" program, for add-ons not already being actively maintained by someone? It would be like "adopt-a-highway", but instead of picking up litter, you continuously upgrade an add-on to work with specific PHP versions and osC versions. That way, there's always a large supply of add-ons that can be counted upon to work, and orphans (duplicate function, poorly written, no one willing to adopt them, etc.) can be purged from the library.

 

Personally, I have so many ideas that could move osc forward by 10 years inside the next year, yet don't have the tools to allow me to do that.

I'm not quite sure where you're heading with this. Are you in need of tools and (compatible) additions to the core to enable all these wonderful changes (and you can't get them in, for some reason), or are you needing to make incompatible changes to the core, that will break 2.x and 3.x, to support the features you want to implement? If the latter, here's a proposal: you start in on osC 4.0 (coordinating with Harald so that the existing 3.0 work is not wasted). Maybe in a year, 3.0 can be released (if at all), and a year or so later, a well-tested 4.0 (or perhaps call it 3.1). That would generate a lot of positive buzz for osC, that finally it has entered the 21st century and is being actively maintained and enhanced. The alternative is just to bite the bullet and fork your own eCommerce product. If you can really move osC forward 10 years within a year, you would get a large following. It sounds like you're really frustrated with the pace of change with osC -- maybe you should just strike out on your own if you feel you're being held back here.

Link to comment
Share on other sites

(trying to get back on topic)

 

One major weakness I see in osC is the need for some form of Guest Checkout. There are several add-ons out there, but all require major core changes. This could either be a hook system that enables developers to write their own Guest Checkout, or one built into the core, and enabled/disabled through Admin.

 

Malcolm

Link to comment
Share on other sites

There is probably an opportunity here to update some of the add-ons to get them into a modular form so they can easily be installed on a going forward basis.   I've hack my core code several times to add a few of the existing add-ons and now that 2.4 is on its way I'm going to need to revisit that again. I suspect others have done the same.  It's probably time we get some of them sorted out.  Maybe as Mr. Phil said "adopt-a-addon" might be one way to proceed and maybe with other more complicated add-ons a group could tackle them.

 

Dan

Link to comment
Share on other sites

  • 4 weeks later...

How do we make dev's and not-dev's aware that addons are all needing to be updated, and that any that are not modular are considered persona-non-grata for Responsive version (and for the upcoming 2.4)?  

 

In Responsive osC we have not actually done that hardly any modularisation - just added a few more simple getContent calls etc.  

All of this modularisation code has been available since (if memory serves) 2.3.1 - that's over 5 years...

The hook code has been available for I think about 2 years, certainly since before the Paypal App...

 

What this means is that any addon created in the last 5 years would/could/should have been modular in nature.

 

Typical Example (I'm going from memory here) is the SPPC addon which changes so much core code that it is pretty much unuseable, and certainly binds you whatever date edge you download and then abuse with SPPC.  With some thinking and practical coding, I believe a bunch of forum users came up with a solution that changes no (or very little) core code.  Great work.  Things like this can be done, but it takes someone or a bunch of someones to sit down and do it.  

 

In the last few days, I've seen some posts where this rings true;

 

 

 

when we try to move the core forward, moan and groan that "addons no longer work", etc etc

 

What everyone need to do understand is that addons needs to be updated to suit core, and that the core does not stay still or get changed to suit addons,  That is the only way forward.  

 

I firmly believe that if everyone pulls together, we can move this quicker - help has pretty much dried up right now other than from 1 shopowner.  Doubly worse, my time is super-limited.  To remedy this it is up to you, shopowners, to stump up your time or your cash to take care of an addon and recode it to make it modular in nature.  Be aware that you (or your dev) can use Modules [ht_, tp_, box, content etc] and Hooks - which means that maybe 75% of addons can be remade without core code changes.  

 

Please note that in the very near future, the following will happen to make things easier.

 

1.  Hook System goes into Core

2.  getContent call on every page

 

Something to think about?

 

if every shopowner using Responsive took care of 1 addon each and coded (or got it coded) properly, that would be hundreds of addons ready for use...in super quick time.

 

if every developer helped out on core for just 15 minutes a day, that would be hours every week of extra coding time moving osC forward.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...