Yeah it was strange, it didn't have an issue on the original code. Only when you downloaded the ZIP or did a fresh clone did it happen! Probably something on the line breaks going awol..MarketInSG wrote:just noticed the commit. broke quite a number of my scripts which searches for footer.
An awesome Web Development company based in Leeds. E-Commerce Specialists by day, Geeks and Gamers by night
Tel: 0845 634 1838
Web: http://www.welfordmedia.co.uk
Twitter: https://twitter.com/welfordmedia
Facebook: https://www.facebook.com/welfordmedia
My biggest complaint, aside from this being a bit of a sellout build, is the coding style differs from the original code.
Little things like spacing before the open/closing braces. It doesn't bother me so much in your own openbay files...but when you change the styling of the engine/controller.php file for the hasAction() function.. that is just annoying. OpenCart's coding consistency is what makes it so great.
Also all the unnecessary clutter of folders. We don't need an "amazon", "amazonus", "ebay", "play", etc folder inside of controller directories. That could have easily been done as a single "openbay" folder with subfolders to keep it all self contained and more importantly removed for those of us that have absolutely no use for any of it. When a single mod takes more folders than the core code, it is time to make a subdirectory.
Little things like spacing before the open/closing braces. It doesn't bother me so much in your own openbay files...but when you change the styling of the engine/controller.php file for the hasAction() function.. that is just annoying. OpenCart's coding consistency is what makes it so great.
Also all the unnecessary clutter of folders. We don't need an "amazon", "amazonus", "ebay", "play", etc folder inside of controller directories. That could have easily been done as a single "openbay" folder with subfolders to keep it all self contained and more importantly removed for those of us that have absolutely no use for any of it. When a single mod takes more folders than the core code, it is time to make a subdirectory.
Also: in the new added translation files it is missing the \\headingtitle, \\text, \\column etc. markings and all the lines are mixed up.
While in other language files the lines are grouped but still the \\ parts are missing.
To me it looks like someone who did the coding that is not instructed how it should be done or how OpenCart files are set-up.
More "strange" way of coding etc. I've seen.
All the new files are missing the >? closing tags?
I agree with Qphoria, why these additional folders which serve NO purpose at all?
What are they different then the other modules, payment and shipping ones?
While in other language files the lines are grouped but still the \\ parts are missing.
To me it looks like someone who did the coding that is not instructed how it should be done or how OpenCart files are set-up.
More "strange" way of coding etc. I've seen.
All the new files are missing the >? closing tags?
I agree with Qphoria, why these additional folders which serve NO purpose at all?
What are they different then the other modules, payment and shipping ones?
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.
Agree with Q and i2paq.
Looks like new parts have been grafted on core, with language strings redundant.
Was not it better to let Openbay, Amazon,... in free extensions as majority will not use ? Paypal update is good.
And does corrected bugs in 2.0 have been ported back in 1.5.6 ?
Looks like new parts have been grafted on core, with language strings redundant.
Was not it better to let Openbay, Amazon,... in free extensions as majority will not use ? Paypal update is good.
And does corrected bugs in 2.0 have been ported back in 1.5.6 ?
I have to say, saying you need to release something isn't a good enough reason to not look through the code. I agree with others that this seems more about adding more mods for OC to generate affiliate cash more than anything, or money received from the various companies to add in their mods. This code could have been pushed to OC's 1.5.6 branch and left for peer review by others before going live. Instead, we've had basically a release with little more than commercial plugins added - even if it was only a couple of days. No disrespect to Welford media, but they should have thoroughly gone through their code to make sure it was written as the rest of OC. This was never happening when Qphoria was part of the dev team, and as far as I can see nobody else has been allowed to push changes without the code conforming to the rest of the cart
Another issue is that we're forced with all of the OpenBay stuff regardless of wanting it or not. I mean every store now is going to be loading 5 extra classes into memory for all of the OpenBay stuff without any need - for those wondering, it's this code in the index.php files
Sure they can be commented out, but they shouldn't be in every store as standard without the user enabling them. This really isn't necessary for the vast majority of stores, not to mention they could quite easily be Model files loaded as required, or even added to the registry by the various controllers. No other modifications load like this - Payment gateways, shipping options and so on all load on demand as they should. While I'm sure time has been spent planning this, it's really not the way it should be coded
For now, I would encourage people to stick with the 1.5.5.X release until this code has been properly reviewed, formatted to standard and streamlined to be as fast as it should be
Another issue is that we're forced with all of the OpenBay stuff regardless of wanting it or not. I mean every store now is going to be loading 5 extra classes into memory for all of the OpenBay stuff without any need - for those wondering, it's this code in the index.php files
Code: Select all
//OpenBay Pro
$registry->set('openbay', new Openbay($registry));
$registry->set('play', new Play($registry));
$registry->set('ebay', new Ebay($registry));
$registry->set('amazon', new Amazon($registry));
$registry->set('amazonus', new Amazonus($registry));
For now, I would encourage people to stick with the 1.5.5.X release until this code has been properly reviewed, formatted to standard and streamlined to be as fast as it should be
Agree!JAY6390 wrote:Another issue is that we're forced with all of the OpenBay stuff regardless of wanting it or not.
We, in The Netherlands, will never use it.
I'll hope it will be removed from 2.0 and offered as a separate add-on.
If not, we will end up like PrestaShop, bloated with 3rd party stuff just to please the sponsers.........
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.
Daniel wrote:need to release something though. the last release was over 7 months ago.
Why not let the 1.5.5.1 CE do the job in terms of bug-fixes and release Openbay as a 3rd party add-on and focus on 2.0?
Now we have to support upgrades, release additional langagepacks en many have to update their Extensions.
And most of all: more bugs, code issues etc. ect.
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 with you on this. And in between I've also noticed a 1.5.5.2 branch on GitHub. WTH!i2Paq wrote:Daniel wrote:need to release something though. the last release was over 7 months ago.
Why not let the 1.5.5.1 CE do the job in terms of bug-fixes and release Openbay as a 3rd party add-on and focus on 2.0?
Now we have to support upgrades, release additional langagepacks en many have to update their Extensions.
And most of all: more bugs, code issues etc. ect.
OpenBay is a free add on which can be found in the extension store. I'm sure plenty of us can download it if we want. Out of all the stores I had worked on, I only see 1 to 2% of them using OpenBay. I don't think we all need integration with amazon etc.
OpenCart is simple enough at v1.5.5.1, let's keep it simple for the rest of the releases rather than complicating everything and slowly ending up like other systems. A clean up is really much needed now..
The closing tag was missing because most code editor omits it. We all agree with qphoria that the coding styles need to be standardized.
OpenCart is simple enough at v1.5.5.1, let's keep it simple for the rest of the releases rather than complicating everything and slowly ending up like other systems. A clean up is really much needed now..
The closing tag was missing because most code editor omits it. We all agree with qphoria that the coding styles need to be standardized.
... So, as usual... We will need to wait for 1.5.6.1 release!
M
Sent from my DesireHD.
M
Sent from my DesireHD.
-----------------------------------------------------------------------
My last mods: Partita IVA e CF | Pro EU VAT Number | Sales Agents | Pricelist Pro
-----------------------------------------------------------------------
I totally agree with i2Paq and the guys, I was looking forward to the exciting v2.0 major release too and I am surprised by this 1.5.6 version, which looks more like a patched-up 1.5.5.1.i2Paq wrote:Why not let the 1.5.5.1 CE do the job in terms of bug-fixes and release Openbay as a 3rd party add-on and focus on 2.0?
Now we have to support upgrades, release additional langagepacks en many have to update their Extensions.
And most of all: more bugs, code issues etc. ect.
I think that the community should be invited to participate in minor releases before publication. A 24 hour final bug fixing session with the community on GitHub could be organised through the forum, the day before a release.
Good job still, the official Paypal integration and partnership was needed and that's good for the future.
OpenCart custom solutions @ https://villagedefrance.net
Promises made over and over again, and broken even morevillagedefrance wrote:I think that the community should be invited to participate in minor releases before publication. A 24 hour final bug fixing session with the community on GitHub could be organised through the forum, the day before a release.
Totally agree, but a separate release for 1.5.5.1 and older 1.5.x version would have been better.Good job still, the official Paypal integration and partnership was needed and that's good for the future.
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 agree with everything that's been said up to this point. Adding further extensions doesn't bother me so much, but the non-standard loading and coding of them just makes working with OpenCart code messier, and more difficult for regular developers.
It seems like it would be a much better idea to create a plug-in download system for these kind of add-ons that aren't generally used. (A lot of the included payment gateways could be part of this, actually.) I'm sure Daniel could make it happen, especially with the extension installer code for 2.0 as a basis.
So true
It seems like it would be a much better idea to create a plug-in download system for these kind of add-ons that aren't generally used. (A lot of the included payment gateways could be part of this, actually.) I'm sure Daniel could make it happen, especially with the extension installer code for 2.0 as a basis.
madimar wrote:... So, as usual... We will need to wait for 1.5.6.1 release!
M
So true
I agree with the many posters here:
- Many of the new files have missing ?> in the end
- Openbay classes should not be loaded for the registry in the index.php, rather, should be loaded on demand as needed, like other extension modules
- Probably quite a few missing bugfixes
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
As far as the coding goes....i would have to agree. Also:
While all of this sounds enticing, it's actually a bad idea for anyone serious about their eCommerce and wanting to offer the best checkout experience possible. It's a cheap way to have something that act's like DIRECT PAYMENT but never will allow you to make it look like it's a part of your store. Anyone that has used the Pay Flow Link on the new Pay Flow Gateway knows this and it should never be pushed as a great idea but only an alternative for particular stores that aren't in the business of wanting to grow their company OR for those that aren't' really concerned about how their checkout page looks. Yes, there are exceptions. I'm talking about the majority of serious eCommerce store owners.
Furthermore,
1) it looks cheap....and the client will still feel as if they are "not on your website" because you'll never be able to style it the way you want it.
2) some folks won't even be using an SSL because of this type of advice which is horrible for business in general. Whether the pages are hosted on Pay Pal or not, a website should always provide a sense of security....period.
My advice: find a way to get approved for a Pay Pal Pro Account and use the Direct Payment Method. This once was called DoDirectPayment but now uses the Pay Flow Gateway. There is a Pay Flow Pro Direct Payment extension for sale in the store and soon my Recurring Billing extension will be released which is the updated version of Pay Pal Recurring Payments.
Thanks for the updates Daniel.
I just wanted to make a few comments on Pay Flow Link (iFrame). While it's great that Opencart is offering this there needs to be some clarification on just how wonderful it is....or not. I feel qualified to make such a comment because I too work with Pay Pal as a liaison for their merchant tools and understand how complicated their system change has made it for some people whether they be developers or store owners or both.Running PayPal Pro in an iFrame allows merchants to hide the identity of the PayPal payment gateway for their card payments. It also reduces the requirements of a merchant’s PCI compliance, so there is no need for a dedicated server or VPS and penetration testing to become compliant - all payment pages are hosted at PayPal and not on your store.
While all of this sounds enticing, it's actually a bad idea for anyone serious about their eCommerce and wanting to offer the best checkout experience possible. It's a cheap way to have something that act's like DIRECT PAYMENT but never will allow you to make it look like it's a part of your store. Anyone that has used the Pay Flow Link on the new Pay Flow Gateway knows this and it should never be pushed as a great idea but only an alternative for particular stores that aren't in the business of wanting to grow their company OR for those that aren't' really concerned about how their checkout page looks. Yes, there are exceptions. I'm talking about the majority of serious eCommerce store owners.
Furthermore,
1) it looks cheap....and the client will still feel as if they are "not on your website" because you'll never be able to style it the way you want it.
2) some folks won't even be using an SSL because of this type of advice which is horrible for business in general. Whether the pages are hosted on Pay Pal or not, a website should always provide a sense of security....period.
My advice: find a way to get approved for a Pay Pal Pro Account and use the Direct Payment Method. This once was called DoDirectPayment but now uses the Pay Flow Gateway. There is a Pay Flow Pro Direct Payment extension for sale in the store and soon my Recurring Billing extension will be released which is the updated version of Pay Pal Recurring Payments.
Thanks for the updates Daniel.
Just wondering, do I have to download the entire 1.5.6, or is there an upgrade? I currently have 1.5.5.1.
Who is online
Users browsing this forum: No registered users and 16 guests
