[1.4.2] Removed the url class? Anymore unnecessary changes?

Well that sunburn hasn't gotten to your brain.

Another well reasoned post. Thanks!

Hope something comes of it.

sunburn1979 wrote:Hi Daniel, thanks for taking the time to post, im a front end designer / developer by trade who has a very keen interest in SEO both on and off site and although I dont under stand the ins and outs of the URL class, from my limited understanding it would greatly aid the SEO of open cart and for me thats a major benefit to any ecommerce system.

Here's the deal: the url class change only affects modders. In some cases it will create a lot more work for them. For regular users it means nothing. For search engine optimization it means nothing.

With my steps to globally replace the bits and pieces, it should no longer be an issue for modders either. At least not at the syntax level. It might still hinder those who may have be manipulating the url with that class.

I guess the real point that I was making was more in versioning structure. You don't remove classes or functions from 1.4.0 to 1.4.1. It would be fine if it was 1.5.0. It's fine to move forward but its frustrating to update mods with every point release

Qphoria wrote:With my steps to globally replace the bits and pieces, it should no longer be an issue for modders either. At least not at the syntax level. It might still hinder those who may have be manipulating the url with that class.

I guess the real point that I was making was more in versioning structure. You don't remove classes or functions from 1.4.0 to 1.4.1. It would be fine if it was 1.5.0. It's fine to move forward but its frustrating to update mods with every point release

So in the end what you are saying that if it stays as it is now there is no need to change it back or change it again?

Seems like Daniel's been given a bit of hard time for not calling 1.4.2 as 1.5, and perhaps not discussing the changes with the community first.

Overall I'd like to congratulate him on taking the initiative to sit down and structure an ecommerce store logically so that there is at last an OS alternative to the developers experience that is OSCommercezencartxcartcreloadedoscmaxhell.

Instead of concentrating on the issue of whether or not the url class is critical/useful/unnecessary the discussion should really be about how the community can structure itself with and around Daniel. At present we seem to have a couple of key commercial addon/template contributors who can see the potential in OpenCart but I get the impression that there is not yet a core development team to help guide OpenCart away from the rocks of community forking. Someone, please, tell me that I am wrong, and that there are plans afoot to help Daniel.

Kurt

cmrukcom wrote:*knip*
Kurt

Hello Kurt,

If you would have taken the time to read around these forums then you would have known that this has been a subject of discussion many times.

The OpenCart project, the OpenCart community and Daniel are aware that changes need to be made and they will be made when things fall into place.
Just be patient

Can you show me where this discussion is taking place and which of the points that I made have been discussed.

Thanks

As been pointed out the problem with removal of the Url class is only specific to people who are making extensions and more specifically those that are modifying URLs, such as for SEO and SERP reasons.

For example would you prefer to see http://www.yourstore.com/index.php?rout ... on/contact (that's if Google shows that entire URL at all) OR something like http://www.yourstore.com/contact-us OR http://www.yourstore.com/contact-us.html

Of course it's better to have the second, BUT without the URL class it's not possible to make that change easily in one place because people cant' show Daniel the use for the URL class.

Basically when building an open source application one needs not only think about the end product and how it woudl be used by end users, but also how it can be used by developers to easily extend and further improve it. This is why such projects as Joomla and Drupal are highly successful and still manage to maintain a well structured code base. Because they have thought out and exposed a hook system to enable people to extend their base without having to pull apart and make drastic modifications to the core code.

Basically what I'm saying is you need to think about ALL stakeholders (end users, developers, etc).

To be honest the idea of branching out as at version 1.4.0 has cross my mind a few times now... The idea would be to use OpenCart as a basis for creating a "Developer's Cart", i.e. a Cart that can not only be used out of the box by end users, but also easily extended by Developers. Kind of a "Shopping Cart Framework" if you will, that would allow developers to take the core and easily extend it to their needs without needing to change every file in the core. I've looked around for something like that for a long time and havn't been able to find anything. Having something like that in my view would create a strong developer community around the project as that will enable people to easily create contributions. It's hard and almost impossible to create a cart that has every feature you want, but if you give people the ability to easily add features then in my view that would be preferable.

So what is the answer or opinion of daniel to the the post from Sheldmandu regarding SEO-Urls?!

snakelab wrote:So what is the answer or opinion of daniel to the the post from Sheldmandu regarding SEO-Urls?!

if you read though all the messages you will see i have anwsed this already.

Yes, and I believe that is a lot of the problem. You are fixing, but also changing the core just about every time. No one can depend on anything being constant.

I've been putting off people who have already paid me for hosting from installing OC until things settle down. You yourself talk about the small little things, and there will always be someone of them. It's the changing the database, changing the structure, the sort of things a couple of your greatest supporters / mods are now complaining about.

I think of it as Tangent Cart. You just seem to go off on a tangent and there is no clear method, just a new idea.

I install carts for a living. I am no coder, I just set them up and help people get selling. But, I've dealt with dozens of them, demo'd probably 50 and always looking, that is how I found that one above. I feel like there is so much potential here, but it is being squandered because there is no plan, it is all hit or miss, fix that, screw what else happens or how many installs have to be modified to keep up.

If it were up to me I'd say go back to 1.4.0 and fix that - without the multi-store. Just get the bugs out to where it was possible for someone who never edited a file in their life to install the cart and run a basic business with no problems.

That's the bottom line - run a business with no problems, but post after post, thread after thread is pretty much common, day to day stuff that is not working as it should. Not a 1 in 1,000 specific application, but just day to day put it up, add some options and start selling.

Why not get that first?

I'm going to agree here, in order for this Cart system to compete with the other cart systems out there, you need
1) Easy upgrade ability
2) Ditch the the features a business would not use (multi-cart for a regular business I've never seen used before)
3) Maintain Database compatibility or at least provide really easy foolproof upgrade / database conversion scripts.
4) Copy and paste-able shipping addresses which are compatible with big name shipping software. As ver 1.4.0 was.
A version system with major/minor/bug/build scheme would be nice too.
I've been using 1.4.0 for some time now, I have to, I ship a lot of packages and need easy copy paste address ability. I am a programmer (PHP, C++, ASM, C, .NET, etc) as well as a business owner. I have a lot of stuff to ship every week, and this cart has some massive potential, but things need to get organized or I fear it will fall apart, I see a lot of people on here griping all the time.Daniel is a good guy, and I know he just want's OpenCart to succeed, as we all do, but people are going to soon seek another cart as upgrades get more complex, I jumped into this right when 1.4.0 came out, which I feel was the best version as well. Any business owners on here moving any reasonable volume of product I think will agree the multi-cart is unnecessary complexity, and 1.4.0 order pages were better suited for quick copy and paste shipping address capability. There are a number of features which I would like to see implemented in OpenCart, which from a business professional's perspective would make this a phenomenal cart system. More statistics is one of them. Anyone who is doing taxes for their business at the end of the year would appreciate that!

12oclocker wrote:

Yes, and I believe that is a lot of the problem. You are fixing, but also changing the core just about every time. No one can depend on anything being constant.

I've been putting off people who have already paid me for hosting from installing OC until things settle down. You yourself talk about the small little things, and there will always be someone of them. It's the changing the database, changing the structure, the sort of things a couple of your greatest supporters / mods are now complaining about.

I think of it as Tangent Cart. You just seem to go off on a tangent and there is no clear method, just a new idea.

I install carts for a living. I am no coder, I just set them up and help people get selling. But, I've dealt with dozens of them, demo'd probably 50 and always looking, that is how I found that one above. I feel like there is so much potential here, but it is being squandered because there is no plan, it is all hit or miss, fix that, screw what else happens or how many installs have to be modified to keep up.

If it were up to me I'd say go back to 1.4.0 and fix that - without the multi-store. Just get the bugs out to where it was possible for someone who never edited a file in their life to install the cart and run a basic business with no problems.

That's the bottom line - run a business with no problems, but post after post, thread after thread is pretty much common, day to day stuff that is not working as it should. Not a 1 in 1,000 specific application, but just day to day put it up, add some options and start selling.

Why not get that first?

I'm going to agree here, in order for this Cart system to compete with the other cart systems out there, you need
1) Easy upgrade ability

while this would be nice. I defy you to find a cart with easy upgrade ability. Even Magento that claims all mods can be done without touching the core and you can always upgrade is full of it if you've ever tried to upgrade a modified cart. And we won't even talk about the upgrade for Zen or any oscommerce based cart.

2) Ditch the the features a business would not use (multi-cart for a regular business I've never seen used before)

well the way it's implemented it doesn't add any complexity for someone who isn't using it.

3) Maintain Database compatibility or at least provide really easy foolproof upgrade / database conversion scripts.

all versions since 1.4.6 have come with a db upgrade script.

4) Copy and paste-able shipping addresses which are compatible with big name shipping software. As ver 1.4.0 was.
A version system with major/minor/bug/build scheme would be nice too.

it is moving in that direction all 1.4.x builds from here on out should be compatible with most mods/themes. There was the big change in 1.4.8 for the token system in the admin, but that was pretty much unavoidable because it was a security issue. 1.5.0 should be the next version with any major changes.

I've been using 1.4.0 for some time now, I have to, I ship a lot of packages and need easy copy paste address ability. I am a programmer (PHP, C++, ASM, C, .NET, etc) as well as a business owner. I have a lot of stuff to ship every week, and this cart has some massive potential, but things need to get organized or I fear it will fall apart, I see a lot of people on here griping all the time.Daniel is a good guy, and I know he just want's OpenCart to succeed, as we all do, but people are going to soon seek another cart as upgrades get more complex, I jumped into this right when 1.4.0 came out, which I feel was the best version as well. Any business owners on here moving any reasonable volume of product I think will agree the multi-cart is unnecessary complexity, and 1.4.0 order pages were better suited for quick copy and paste shipping address capability. There are a number of features which I would like to see implemented in OpenCart, which from a business professional's perspective would make this a phenomenal cart system. More statistics is one of them. Anyone who is doing taxes for their business at the end of the year would appreciate that!

well being that you are a PHP developer I'm sure everyone here would welcome you writing some statistical reports. It's not really a major task.

well the way it's implemented it doesn't add any complexity for someone who isn't using it.

that's a relief. I remember installing one of the new version and it was rather puzzling as to what to do with that.

all versions since 1.4.6 have come with a db upgrade script.

I'm sitting at ver 1.4.0, and have not found any well documented notes on what changed in the db, I have made a copy of the store and upgraded, but there were some major problems, and a few drawbacks in the newer ver, such as copy-pastable shipping addresses, so I reverted back. Still would be nice to have a script starting at least at ver 1.4.0 to jump to the newest ver.

well being that you are a PHP developer I'm sure everyone here would welcome you writing some statistical reports. It's not really a major task.

As i stated in the framework explanation post, it is kind-of a task when you have no idea how the framework is designed, I'm sure you have sifted through all the code by now and have a general idea, I work at least 12hr everyday, and don't really have time like I used to. My lack of time is of course no reasoning for it, I am just comparing to other open source projects which seem to have less lack of documentation. If we had some documented functions, and documented file locations. things would really pick up.

the upgrade script for the db will work as far back as ver 1.3.2. Now of course if you have a highly modified store an upgrade is not going to go smoothly, but that's pretty much the way it is with all programs.

as far as the framework goes even though it's not documented it's fairly simple mvcl style framework. similar to codeigniter, so you'll be looking at 4 files for each page. a controller for the programmming logic, a language file (self-explanatory), a model file for the database access, and a view file for the presentation(HTML).

Qphoria wrote:1.4.0 should be 1.5.0 since the template system and engine code (router to action) and language class was destroyed
1.4.1 should be 1.6.0 since the url class was destroyed.

How was the language class destroyed? 1.4.2(3) seems a lot more compact in regards to code size with a bit moved to index.php

Is the url class coming back with 1.5?

How could the url class have solved the token issue being pasted throughout the admin?
Would you just tag on the token in the class?

SapporoGuy wrote:
Is the url class coming back with 1.5?

How could the url class have solved the token issue being pasted throughout the admin?
Would you just tag on the token in the class?

the latest report is that yes the url class is coming back in 1.5 It wouldn't have solved anything by itself, it just would have made the solution easier. Since every url is run through the class you can modify every url from one place. Same with some of the seo tricks people were doing before it was removed. And supposedly this time it's going to have some sort of hooks in it which should allow you to do some really interesting things, though all this could change of course.

SapporoGuy wrote: How was the language class destroyed? 1.4.2(3) seems a lot more compact in regards to code size with a bit moved to index.php

The language class was destroyed in the sense that unlike all other library methods:

$this->currency->getCode()
$this->cart->getProducts()
$this->tax->getRate()

It used to be:
$this->language->getCode()

Now we use a very unorthodox method of polluting up the index.php file, and then replacing the config variable that is originally pulled from the database.
$config->get('config_language');
...check language cookie or change....
$config->set('config_language', $languages[$code]['code']);

done in the index.php file.

$this->language->getCode()
and
$this->language->setCode()

make much more sense and follow the standards much better IMO

It also allows us to do the same that Xsecrets mentioned in terms of manipulating ALL values in a single place.

Unfortunately with the new url class, the way daniel wants to use it, it won't actually help the token system. He wants to keep it generic and pass the token as a query variable, instead of just "assuming" it when on the admin side. Not to say it's wrong in very strict logical programming... but this is what makes life difficult for programmers... finding that gray area between the strict proper way, or the semi-strict proper way.

If we followed a semi-strict way, the code would be smaller and easier to extend, but who knows if that would be problematic in the future. Instead we follow an extremely strict method (daniel is a very strict programmer) so it means we have a lot of duplicate code because its more "proper" in terms of programming techniques, but clashes with the way we split our code.

hmmm, "strict programming techniques" sounds more like the latest in "how things should be done" ... I wonder what happens when a new theory comes along and the current way goes out the door?

Anyway, I would think moving things into their perspective "class" would make more sense and I do agree with after looking at the index file that I do not like the pollution and how it's going to come back and bite you that you didn't move associated code into their own cubby hole. I wonder if there is a trade off between programming properness and organized code?

Also, from a template and controller standpoint, I don't like the longer code. I would prefer IF there is no security difference that the token be added within the url class since it is part of the url.

And splitting hairs on microseconds, wouldn't less characters per file make more sense? You know like how jquery gets minified?

Guy dropped in the other day - "Been about a year since I was here. Looks like it's still a one man show. I guess I'll come back in another year and maybe it will be straightened out." Not his exact words, but close.

Another year later and I see nothing has changed... It's sad because I think opencart has potential. I'm a developer, and have yet to make a site with opencart, because as flexibile as it is, some of the items raised in this thread are bottlenecks that need to be addressed.

I see the same arguments now (a year later) that are in this old thread... Such a shame to see this lack of progress. :-/

mfive wrote:

Guy dropped in the other day - "Been about a year since I was here. Looks like it's still a one man show. I guess I'll come back in another year and maybe it will be straightened out." Not his exact words, but close.

Another year later and I see nothing has changed... It's sad because I think opencart has potential. I'm a developer, and have yet to make a site with opencart, because as flexibile as it is, some of the items raised in this thread are bottlenecks that need to be addressed.

I see the same arguments now (a year later) that are in this old thread... Such a shame to see this lack of progress. :-/

You are just reading an old thread.
url class has returned
the index file has been cleaned up
Don't rely on what you think you know based on a year old thread to decide what is happening.