Post by jawaid » Tue Jan 10, 2012 12:02 am

Hi everyone,

I might be off topic but the topic seems relevant so I'm posting here. What actually I want is to add some functionality in the core ie. engine and library. I am new to OpenCart so I would appreciate if anyone can tell me some useful resources to get acquainted with the core system and some tips about it.

Thanks in advance.

Jawaid


Newbie

Posts

Joined
Mon Jan 09, 2012 11:48 pm

Post by straightlight » Tue Jan 10, 2012 12:09 am

The most commonly known functionality for this and apparently preferred is VQMod.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Opencart.com Administrator / Quality Assurance Analyst / Programmer


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by 2dawgs » Mon Feb 06, 2012 9:21 am

Qphoria wrote: That isn't what it sounds like based on that brief description on their site.
Overrides

Any file in the first two locations above can be overridden by the same file in the third location. This lets sites override presentational and controller logic for custom applications and display, without forking core code bases or packages acquired from the marketplace.
Looks to be just like the single file-based override that straightlight mentioned and limited to one mod per file.
As far as strictly overriding existing programming, yes. But what you can also do is to create additional versions of existing blocks (which you would have to give different names to), that can all co-exist in the same installation, which you can select between when creating pages and inserting blocks of content. You can use them in place of the ones provided in the core, or in place of one that overrides the one provided in the core. You can use different ones in different places in the site or even on the same page, but obviously, you can't use more than one in the same place on the same page.

I guess the advantage of this that I see, is that it does not require embedding your custom code in an xml file, you can just create new versions of the code you want and drop them into the designated location. The dispatcher knows which one to use based on its location in the file system, and on which custom block you select when adding content to a page. They don't get blown away in a system upgrade, either. (Although they may not necessarily work afterwards either, but at least they don't just get overwritten.)

What I hear you saying is, what if you want the modifications from more than one 3rd party developer to be applied to one block of code? My reply is, good point. I haven't yet run into that scenario with C5 after working with it for 3 years, although I've developed some custom blocks for it, and have used them in conjunction with others from elsewhere. I suppose that is a more likely scenario with OpenCart, since the content that goes in the pages of OpenCart is relatively fixed, and needs to be, because it's designed for a more specific purpose - to organize and display products for sale.

The site I'm working on now is my first experience with OpenCart. Maybe I should take more time to understand it more fully before the next time I open my trap. ;D

Cheers!

New member

Posts

Joined
Sat Jun 11, 2011 5:26 am

Post by kabojnk » Sun Jun 10, 2012 6:32 pm

Sorry to engage in some thread necromancy here, but I just came back after checking in to see if OpenCart had ever implemented some sort of hooks system since I first posted this thread. I'm a little disappointed that it hasn't gone this way, and the only reason I'm saying that is because this shopping cart system is probably the best one out there for developers who like lightweight MVC-style PHP frameworks.

But again, it's not extensible in a scalable way. That's the equivalent of a boner killer for serious developers.

I'm a big fan of the book "The Practical Programmer" (http://amzn.to/IsvTeL), which many developers consider to be the industry's bible. I just wanted to point out a few concepts that have their own entire chapters in that book. The first and most important concept is modularity. Ideally, modules should minimize its dependencies on other modules and/or the core. Everyone's idea of an ideal plugin is something that can be enabled/disabled without having to alter the core or other systems, and something that can can hook into the core consistently through each version update to the core itself.

vqMod is a stopgap measure to allow for some degree of modularity, but it's still essentially just an elegant find/replace system that patches the core. Any serious developer can easily point out the flaw in the logic of patching the core to install plugins. This is by no fault of Qphoria, who is just doing his best given the circumstances.

The second concept I wanted to talk about was scalability... and I think the biggest problem is that OpenCart retains a cathedral style of development. Sure, the solution is scalable for Daniel and his core code. And there's no problem with the cathedral style when it comes to developing consumer software like music players and video games. But when you're developing software that's intended to be extended by other designers and developers to serve the needs of their clients, the software needs to be scalable for them as well in ways that go well beyond what is usually provided in the core. If there's one good rule of thumb when it comes to ecommerce sites, it's that every client has at least one edge case need that isn't provided by the vanilla version of the software.

Denying developers a system for creating modular code that operates on top of the core causes major scalability issues for those third-party developers. Good developers don't want their plugins to be patched into the core, nor dependent on a plugin like vqmod to operate. Imagine how hectic things could get if core gets updated by vqmod doesn't, or if there's an error in vqmod that causes _all_ plugins to break. Or what if you install someone else's plugin (patched into core) and it breaks the system when your plugin's patched into core as well? There are too many unknowns to make this platform popular with developers who want to write good code.

This thread has already discussed the fate of osCommerce. But the point is so important that it bears repeating that osCommerce failed mainly because it was a non-modular, non-scalable shopping cart system. I think everyone can say the same thing for ZenCart (the osCommerce fork) as well. Every long-lived, successful shopping cart system and CMS has some sort of module/plugin system in place that does not overwrite core code. Even the ones that suck horribly still beat the snot out of non-modular systems. Even the big enterprise systems like JBoss/ATG Dynamo, custom tailored for large corporations, maintain modularity and scalability.

It seems to me that OpenCart is at a crossroads. If it keeps down the same road, I'm suggesting that its lifespan for OpenCart will be much shorter than what it could be. Someone could easily develop a similar MVC-style application in FuelPHP or CI or Kohana in a year or two, boasting i18n and hooks system, and simply draw designers and developers away from using OpenCart.

The systems that already exist are nowhere near the right spot that OpenCart could be in. I think that most developers can agree that Magento and the Zend Framework are no shining paradigm of a "lightweight" MVC framework. And the other existing shopping cart systems are disappointingly crappy, outdated and/or undermaintained. OpenCart, on the other hand, is actively maintained and has a rich set of features. The only thing it needs is scalability.

I'm sure I won't be the last person to bring this up, either. But I'd really like a definitive, logical explanation as to why modularity is not a priority for this project. Even if it's just Daniel saying "STFU, I built this for myself and my clients and I'm just being nice enough to let the rest of you enjoy it as well," I'm fine with that. And if that were the case, maybe I will just bite the bullet and write something myself, even if it might take longer. Because even though freelance is something I do on the side, it's still a pain having to deal with this issue.

Newbie

Posts

Joined
Mon Oct 24, 2011 4:36 am

Post by Qphoria » Tue Jun 12, 2012 1:14 am

kabojnk wrote:<snip>
I think you'll find most of us agree with you. vQmod is indeed born from the lack of structured plugin system. The idea has been discussed a few times and at those times Daniel was not keen to add a plugin system. A few other devs (including myself) have pondered using vQmod to implement a plugin system that could hopefully prove itself worthy enough to convince daniel to add it, but it has fallen on the way back burner for me and nothing has come to fruition from any others yet.

So we certainly welcome your input on this and hopefully someday something will be born of this.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Avvici » Tue Jun 12, 2012 12:27 pm

VqMod does what it's supposed to do, and nothing more. As a developer myself I used it to develop a couple extensions and in doing so immediately found some impracticalities that simply were not intuitive to me. That being said, who F___in cares. :crazy: It does what it's supposed to do and does it well as we all know. Whether it was an attempt to "begin" a visionary process into making OC more modular well...okay. I also had visions of gaining more hair growth on my head by taking Rogaine but instead I lost more.

I'm on board with kabojnk and xsecrets and their statements. I have high hopes for the cart. O0

User avatar
Expert Member

Posts

Joined
Tue Apr 05, 2011 12:09 pm
Location - Asheville, NC

Post by kabojnk » Wed Jun 13, 2012 10:25 am

Cheers for the replies. Definitely didn't want to crap on vqmod either, despite how rant-y my post was. I think it's definitely the best solution given the circumstances. :)

I'd love to hold out hope that OC gets plugin/module integration, too. I can probably hang on for a bit longer, too, because I'm not in complete dire need of a cart system at the moment. Part of me wants to write my own... I've written two other cart systems from scratch in the past, but nothing for general use. Plus, time and need are two things I don't have ever since leaving freelance development... hence my hesitance. Plus there's the whole re-inventing the wheel thing. If I were to do it, I'd at least be able to make it the way I need it to behave, and then I'd throw it up on github so others could contribute what they want out of it.

But, maybe the best (and most realistic) solution is to have just one plugin that patches the core... that updates when OC updates... and that inserts all of the hooks and modularity connectivity necessary for people to create real, modular plugins. Sounds a lot more pragmatic at the moment. It would just require that one plugin to keep up with the release cycle of OC, and that's already been proven doable since vqmod pretty much does that already. :)

Newbie

Posts

Joined
Mon Oct 24, 2011 4:36 am

Post by JNeuhoff » Fri Jun 15, 2012 5:15 pm

kabojnk wrote:Cheers for the replies. Definitely didn't want to crap on vqmod either, despite how rant-y my post was. I think it's definitely the best solution given the circumstances. :)

I'd love to hold out hope that OC gets plugin/module integration, too. I can probably hang on for a bit longer, too, because I'm not in complete dire need of a cart system at the moment. Part of me wants to write my own... I've written two other cart systems from scratch in the past, but nothing for general use. Plus, time and need are two things I don't have ever since leaving freelance development... hence my hesitance. Plus there's the whole re-inventing the wheel thing. If I were to do it, I'd at least be able to make it the way I need it to behave, and then I'd throw it up on github so others could contribute what they want out of it.

But, maybe the best (and most realistic) solution is to have just one plugin that patches the core... that updates when OC updates... and that inserts all of the hooks and modularity connectivity necessary for people to create real, modular plugins. Sounds a lot more pragmatic at the moment. It would just require that one plugin to keep up with the release cycle of OC, and that's already been proven doable since vqmod pretty much does that already. :)
I am actually working on a proper plugin system in my spare time, have all the major issues resolved, including that of different plugins modifying the same OpenCart core file. I am just very busy at the moment with some other projects, but hope to get it finished soon.

MHC Web Design
Override Engine * Integrated VQMod * Unused Images Manager * Instant Option Price Calculator * TrustPilot Reviews * Google Rich Snippets * Google Tag Manager * Export/Import Tool * Template Switcher PHP/Twig


User avatar
Expert Member

Posts

Joined
Wed Dec 05, 2007 3:38 am

Who is online

Users browsing this forum: Bing [Bot] and 5 guests