Who came up with that clever Gorilla marketing strategy?
Serious; why not just use vQmod instead of OCmod and Override Engine?
Do we really need 3 different modification engines for just one piece of software?
Do they even work together?
And if I read right, OCmod is a poor mans vQmod?
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
Yepi2Paq wrote:So we have vQmod, OCmod and Override Engine?
I agree about ocmod, but Override Engine has it's own features that make it useful and really isn't anything like vQmodi2Paq wrote:Serious; why not just use vQmod instead of OCmod and Override Engine?
Not right now noi2Paq wrote:Do they even work together?
Pretty much yeahi2Paq wrote:And if I read right, OCmod is a poor mans vQmod?
BTW.: There are 4 ways of modifying OpenCart core files:
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Wauw!JAY6390 wrote:Yepi2Paq wrote:So we have vQmod, OCmod and Override Engine?
I agree about ocmod, but Override Engine has it's own features that make it useful and really isn't anything like vQmodi2Paq wrote:Serious; why not just use vQmod instead of OCmod and Override Engine?
Not right now noi2Paq wrote:Do they even work together?
Pretty much yeahi2Paq wrote:And if I read right, OCmod is a poor mans vQmod?
Who could imagine when vQmod came out you guys (reed: Extensions builders) would have to build 3 (or more) versions of your extension to be able to sell them to people using OpenCart.....
Could we PLEASE(!) use vQmod in the core of OC instead of ocMod?
It's like buying a BMW 5-series but instead of having a 2.0 liter engine you buy it with a 1.6
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
I am coming around to this soon and will be asking for feedback and opinions on what is missing, needed, nice to have etc
I appreciate there will be disagreements on "the best way" but I will look at everything and then put it to Daniel to discuss. Obviously Daniel wants people to use OCmod, developers want to use vQmod, I just want what ever is going to work best for everyone.
Ideally (IMO) Jay and Qphoria would best best to head up the "default" integrated file modification solution - they have more experience in that area, but that's down to them and Daniel
I'll be back to discuss this v soon though.
J
http://forum.opencart.com/viewtopic.php ... 30#p494330
Anybody, please feel free to use it if you want.
IMHO, both VQmod and OCmod are not the longterm solution as a system for modifying OpenCart core files.
Using hooks (OC 2.0 has something like this in the form of event handlers for model classes), or overridden methods in extended core classes should be the prefered way. We need to move away from the reliance of exact source code matches for modifying core files.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Use 3rd modification method is optional, but would be redundant for user and developer when it comes to conflicting with ocMod. Furthermore there is another "Event" handler that probably the closer features to plugin/ hook mechanism.
My only concern is will ocMod properly documented and tested before OC2 stable is released.
I'm afraid the experience with 1.5.x is repeating, where most new version contain change at framework level without notice.
IMO it's good time to implement better management.
Once OC2 is released in hurry under stable while there is still discussion at framework level it would be disaster for everyone.
Still, it should probably be set in ocmod to support position in either position and if it is in both then only use the one from the <add> tag. That is what the plan for vQmod was going to be, so that ocmod and vqmod scripts could be cross compatible.... but there also see to be some other things like the "after" position acting more like "inline-after" instead of going to a new line so I'm not too keen on that. Perhaps a break down of the differences between ocmod and vqmod is needed first to determine what would make ocmod better or more compatible.. or if the changes are worth a new syntax.
Has there been no discussion about this but just "heck, lets just ignore vQmod and all the developers and just make something up", "Who cares that we have 1000nds of vQmods all over the forum and make them useless and have everybody re-invent the wheel"?
Really
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
Didn't really want to start on this topic in detail for a few more days but I guess it's pretty much THE most important feature when it comes to revenue generation for OC and looking after the mod developers, so yeah lets get started on trying to resolve this.
I think the concept behind the ocmod system was great - a native vqmod type system. But I do think that it is unfinished/missing too much and will be a deal breaker with many devs as already mentioned. It needs to be better before its accepted.
So the current options are:
1. Scrap OCmod for 2.0 and spend more time on it for say 2.1, use vQmod for now.
2. Improve OCmod for 2.0 but will very likely delay the 2.0 launch. Make it at least inline with vQmod and make the scripts backwards compatible.
FYI no matter what you say you preffer I have zero control over the choice, it is down to Daniel.
I 100% agree that dropping compatibility for thousands of modules is a bad idea, I am not bothered about creating new modules using a new system but if the new one doesn't do all and more than what the old one does - then people will not bother and OCmod will flop.
Qphoria, I think that just about nails itbut figured I might be able to improve adoption by using a syntax that other's have used so I kept it.
Basically right now its a mad house trying to get everything inline to get this release done, but everything so far I have tried to make sure it's done right. I will speak with Daniel tomorrow or Monday and discuss options and solutions, I don't really want to take over looking after the default modification system (what ever it ends up being) but if Daniel doesn't have the time to make the changes then I'll step in.
J
A oui!James wrote:Think you may mean pardon mon French
Option 3. Delay 2.0, get vQmod in and lets do it right for the first time.So the current options are:
1. Scrap OCmod for 2.0 and spend more time on it for say 2.1, use vQmod for now.
2. Improve OCmod for 2.0 but will very likely delay the 2.0 launch. Make it at least inline with vQmod and make the scripts backwards compatible.
FYI no matter what you say you preffer I have zero control over the choice, it is down to Daniel.
No backwards compatibility issues, current vQmod script will (almost) work out of the box.
Investments made in current scripts by OpenCart users will keep their value.
No new learning-curve(s) + 1000nds of topics on our forums regarding ocMod and its (non)function or "hey, my xml is not working!" (no, because it is a vQmod script and not an ocMod script....)
No issues where vQmod is not working next to ocMod.
Bad idea?I 100% agree that dropping compatibility for thousands of modules is a bad idea, I am not bothered about creating new modules using a new system but if the new one doesn't do all and more than what the old one does - then people will not bother and OCmod will flop.
Why did no-body came up with this before?
Because, and yet again, things like this have NOT been discussed!
Why is Daniel not in this discussion, it was his decision to go this path.
I was told, some time back, that vQmod would be integrated and not something called ocMod.
Come on, we have been waiting for 2.0 some time now and waiting some more won't hurt OC.
Releasing it with ocMod while vQmod is around is some of the wost marketing you could do.
This will hurt OC and make all our enemies lough their heads off.
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
+1i2Paq wrote:Come on, we have been waiting for 2.0 some time now and waiting some more won't hurt OC.
IMO, with alpha introduction in August, my prediction OC2 will launch at January 2015.
There is still several month to discuss and do more test.
OpenCart 2 will mature through several release that hurt extensions,
or open more discussion and do test as much as possible before launch stable release.
I have had a discussion with Daniel about this on github a while ago. In the end Daniel decided to use his own OCmod XML syntax instead of the VQmod XML.i2Paq wrote: Has there been no discussion about this but just "heck, lets just ignore vQmod and all the developers and just make something up", "Who cares that we have 1000nds of vQmods all over the forum and make them useless and have everybody re-invent the wheel"?
Really
If Daniel doesn't include VQmod XML syntax support, it won't be the end of the world, I have already released support for VQmod XML for testing, and will also make it available on the OpenCart Extensions once OpenCart 2.0 is released. So there is no need to worry about loosing past investments of existing VQmod XML scripts, even though most existing VQmod files will have to be reworked and upgraded to work with OC2 anyway, because the OC2 core files are quite different from those of OC 1.5.x.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
I cant believe that the long awaited v2 would be launched with anything less than a fully operational VQmod/ocmod that operates as it does now (doesnt matter what its called). As JNeuhoff says devs will have to re-do their mods as so many core files will have changed but I think less features or a change in syntax etc maybe a change too far.
JNeuhoff also nails it for me with the notion of a hook system like Wordpress. If this is introduced though I think it prudent that its run alongside a vqmod system until devs fully adopt the hook system. A comprehensive dev guide to a new hook system should also be written up for dumb bums like me to follow.
But yeh we all know vqmod and how it works, dont change it, just integrate it, save a whole lot of moaning thats for sure
OpenCart Theme Options - See All My Extensions - OpenCart Themes and Mods
the hook system is actually in place already and works really wellThePath wrote:JNeuhoff also nails it for me with the notion of a hook system like Wordpress. If this is introduced though I think it prudent that its run alongside a vqmod system until devs fully adopt the hook system. A comprehensive dev guide to a new hook system should also be written up for dumb bums like me to follow.
https://github.com/opencart/opencart/wi ... fications)
it also has a feature not yet documented where you can read and manipulate the data before it gets added to the database which was well needed imo
https://github.com/opencart/opencart/co ... nt-7312888
+1ThePath wrote: But yeh we all know vqmod and how it works, dont change it, just integrate it, save a whole lot of moaning thats for sure
imho vQmod and vQmod Manager should both be integrated into 2.0
It looks like OC 2.0 will have a more robust system than vQmod Manager though I haven't had time to check it out.dabomb59404 wrote:imho vQmod and vQmod Manager should both be integrated into 2.0
I'm gonna be odd man out and say I'd rather neither vQmod nor OCMod were integrated. Leave vQmod as an add-on and have the OpenCart core concentrate on expanding the Events system.
PHP has matured rapidly in the last few years. Just imagine the power of a Composer-like system for mods. Users could pull and update mods straight from OpenCart and developers could rapidly create code using modern programming tools. It would even allow for a certain level of digital rights management.
-Ryan
Users browsing this forum: No registered users and 60 guests