Replies: 7 comments 7 replies
-
Wow! Thank you so much for doing God's work in keeping the real Magento up-to-date! |
Beta Was this translation helpful? Give feedback.
-
I think it's important that people are aware of how big a change the API Namespace actually is. For some, it may be nothing, but for others, it could break your integration. The release notes for version 20.0.15 suggest that the fix is to change any hardcoded API configurations that use "urn:Magento" and change them to match the current NS. But that will only work if the 3rd party client that's connecting to your site doesn't care what the namespace is. Some do!!! In our case, Listrak was not compatible with OM, and the ONLY reason was that they expected "Magento" for the namespace. After overloading the core to change the namespace back to "Magento" everything started working again. My personal feeling is that this should NEVER have been changed in the first place. There's really no reason for it other than divorcing yourself from the old Magento branding, and changing it seemed to only cause problems and didn't solve anything. It is what it is, but buyer beware. If you're upgrading an existing Magento install, pay special attention to any API connections that may break. |
Beta Was this translation helpful? Give feedback.
-
We fixed several bugs and yet reported why this was bad in first place, but now its done since months. |
Beta Was this translation helpful? Give feedback.
-
I'm glad to see such great discussion on this topic. To be clear, I posted this as a heads-up to anyone coming here in the future. We did run into this problem about a month or so ago when we first launched OM (we were on Magento 1.9 until September of this year). So I was not a part of the project until recently. At that time, I actually struggled to find answers to the problem, so it's actually a bit of a surprise to hear that it's a known issue that has caused so much industry headache. I am not suggesting it be changed back, I agree that would be a PITA. What's done is done. However, 5 months isn't actually all that long in development timelines. Moving from a system you've had for a decade takes time, and customers will be moving from Magento to OM for years to come. If nothing else, highlighting this concern so that it's easy to find when future customers come here looking for answers is still beneficial :) |
Beta Was this translation helpful? Give feedback.
-
The change was not made because we wanted to replace the word Magento with Openmage, but it had a solid reason. I asked for explanations at that time and I received them, especially since I didn't like a hardcode solution. I think I was one of those who approved the PR. It was known that there would be isssues, that's why a Readme was created on this topic, with the "Changes to SOAP/WSDL" section. When it was reported the solution came quickly and many solved their issue until a new version was released. I'm sorry to hear that in some cases the solution took longer, but it's good for the maintainers to be aware of the changes and if they encounter issues to report them immediately. I have made my changes in my stores so far and I actually faced this issue when it was reported. Reverting to this means turning things upside down for everyone who tuned in when 20.0.15 was released. |
Beta Was this translation helpful? Give feedback.
-
The bad thing is it was hadcoded and not configurable via system.xml. Reason was that they had issues with code testing, but that from my pov clearly should subordinate. They did not think of there are custom soap calls that use the old URN ending up in mixing URN information in WSDL. |
Beta Was this translation helpful? Give feedback.
-
We have at our disposal a powerful information tool for such situations, but it is not used https://github.com/OpenMage/Web_Notifications. Important changes, new versions, can be announced in the Backend whenever necessary. |
Beta Was this translation helpful? Give feedback.
-
Overview
This is a bugfix release with a couple of really good enhancements.
In the meanwhile we're working on completing the full PHPStan validation, which is allowing us to reformat the whole source code to make it look more beautiful than ever.
Last but not least, we already merged 2 PRs for the upcoming PHP 8.2 support!
Important things you should check before upgrading
What's Changed
<pre>
tag for prettier error print. by @kiatng in Enclosed error with <pre> tag for prettier error print. #2368New Contributors
Full Changelog: v20.0.15...v20.0.16
This discussion was created from the release v20.0.16.
Beta Was this translation helpful? Give feedback.
All reactions