see Daniel's News Announcement, 2nd line of the "Added" section and the "REMOVED" section: viewtopic.php?f=2&t=228481
Already discussed here in this forum several times in the past - where have you been??
Full Stack Web Developer :: Dedicated OpenCart Development & Support DACH Region
Contact for Custom Work / Fast Support.
My Github OC Site: https://github.com/IP-CAM
5'200 + FREE OC Extensions, on the World's largest private Github OC Repository Archive Site.
Urgent Questions shoot here: khnaz35@gmail.com
Enjoy nature
It was expected from the very beginning. It was absolutely unnecessary to remove OCMod, but nobody listens to developers when it comes to adding/removing features to OC.
Professional OpenCart extensions, support and custom work.
Contact me via email or Skype by support@thekrotek.com
Upgrade Service | OC 2.3.0.2 PHP 8 | My Custom OC 3.0.3.8 | Buy me a beer
Great, it will then end up with about the same problems as experienced already in OC v.2.x and v.3.x
My Github OC Site: https://github.com/IP-CAM
5'200 + FREE OC Extensions, on the World's largest private Github OC Repository Archive Site.
I could port our Integrated VQmod (which supports both VQmod XML or OCmod XML) to OpenCart 4 if there is sufficient demand for it. It would work like the OpenCart 3 OCmod.
Having said that, XML-based modification systems are not the longterm solution. XML is a structured markup language for documents or protocols, it is not meant to be a programming language. What OpenCart really needs are more trigger points for events, and proper extension mechanisms, such as chained class extensions, support for decorator design patterns, etc.
The danger with XML based modifications for OC 4 is that we'll see all these poor quality extensions again.
The OpenCart marketplace really needs a quality control or vetting process of some sort for 3rd party extensions.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Well, that would at least solve this Problem for good, because otherwise, it will end up in Chaos again. You just have to make sure, that the 'Owner' of the VqMod Name will accept your Proposal, since VqMod seems to be a 'registered' Trademark Name, as quoted already by it's 'Owner'. You just have to accept the Fact, that OC-Newcomers have no Idea on such 'Details', and they use, what they get.I could port our Integrated VQmod (which supports both VQmod XML or OCmod XML) to OpenCart 4
It would be a real Progress, to make OC v.4 to be a Success.
My Github OC Site: https://github.com/IP-CAM
5'200 + FREE OC Extensions, on the World's largest private Github OC Repository Archive Site.
Urgent Questions shoot here: khnaz35@gmail.com
Enjoy nature
Events should be used for extension/modules which make "changes" in the core and not to upload extension whitout core changes: like bank transfer payment, language files if will be the case....
https://github.com/opencart/opencart/di ... nt-2818749
Upgrade Service | OC 2.3.0.2 PHP 8 | My Custom OC 3.0.3.8 | Buy me a beer
Thank you to all of the legends in this thread. You all rock and always will.
Retro is in and vQmod is back
Long live the Queen !
DISCLAIMER:
You should not modify core files .. if you would like to donate a cup of coffee I will write it in a modification for you.
https://www.youtube.com/watch?v=zXIxDoCRc84
Let's consider this example. I want to change the validation for the postcode to only accepts characters which are numeric.
catalog/controller/account/address.php
Line 293:
Code: Select all
if ($country_info && $country_info['postcode_required'] && (utf8_strlen($this->request->post['postcode']) < 2 || utf8_strlen($this->request->post['postcode']) > 10)) {
Code: Select all
if ($country_info && $country_info['postcode_required'] && (utf8_strlen($this->request->post['postcode']) < 2 || utf8_strlen($this->request->post['postcode']) > 10 || !is_numeric($this->request->post['postcode']))) {
But as he says there its a bit convoluted as you need to handle the setup for the find/replace code yourself and effectively writing your own code for each change to do what vQmod already does at a wider scale with portable scripts.
The event system is powerful but I think it should be limited to calling functions based on a certain step triggered in the process.
For example if you want to send some data to a 3rd party marketing campaign, you could make an event to send that data after each of these (but not limited to) available events. Again these are just sample events but effectively show all the potential places some event can be "triggered"
before/after registration
before/after addtocart
before/after enter shipping address
before/after enter payment address
before/after enter coupon
before/after place order
So pretty much any "action" that you can do in the cart, can then call to some trigger which allows for custom "events" to be run or "functions" to be called that are assigned to that trigger event. But it isn't granular enough for changing small things like adding/removing fields or custom lines of code which is where vQmod comes in.
Users browsing this forum: Bing [Bot] and 66 guests