Many problems with oxid eshop 2

English forums
1

Not sure why and who closed that topic. There are so many issues on very long buggy unoptimized journey of upgrade.

Is this project really dead? It looks like from forum here too.

Anyway, it looks like something changed and pictures not generating now properly, all prices are zero although existing in db, bad formatting, only some pictures working. Apex messed it all?

Just curious why there are upgrade documents which dont work at all?

Also still dont understand why upgrades are so painful and why the hell so many restrictions and unsupported stuff among versions. Nonsense and big probability of complete fail.

2

Regarding forum activity / “Is the project dead?”:
Activity in this community forum is not a reliable indicator of the project’s status. OXID is constantly evolving; new shop versions are released regularly, there is a dedicated website, new modules are released on an ongoing basis, and there is the Solution Hub for extensions and partner solutions. For context: This forum is a community resource and not an official OXID support channel. It is intended for general discussion, where developers and users voluntarily support one another. For official support, please contact OXID Support or the partner network. For official support, please contact OXID Support or the partner network.

To provide targeted assistance in this thread, it would be helpful if you could provide the following information:

  • the exact error messages from the log regarding the current issues (images, prices, formatting) similar to the `implode` error in your previous inquiry.
  • whether the existing modules from the 6.5 installation were deactivated or removed after the update to 7.0. Modules that were not written for or made compatible with OXID 7 are a common cause of exactly these kinds of symptoms and are often unrelated to Apex or the core update itself.

Additionally, here’s a note that has already been raised in the old thread: Given the many intermediate steps and legacy issues, it may be easier and faster in some cases to set up a completely fresh, up-to-date OXID installation instead of performing a step-by-step update and then simply re-importing the product data (as well as customers and orders, if applicable) rather than guiding the existing, established store through the update module by module and error by error. For generic import/export of product data, see the official documentation: Generischer Export und Import — OXID eShop 7.5 | Anwenderdokumentation . For more advanced requirements (e.g., more complex data migration, custom fields), it’s worth checking out the Solution Hub, where you’ll find specialized solutions for some of these scenarios: https://solutionhub.oxid-esales.com/.

Note on the title: Adjusting the thread title, for example, to “6.5 → 7.0 Update: Images, Prices, Formatting After Apex Update” would make it easier for other users to find or even spark their interest in the topic in the first place. The more focused a thread title is, the more likely someone who can contribute to solving that exact problem will find and read it.

3

Thanks for your reply.

I believe you must be joking. Please cant you see there are a lot of issues in what you said?

I would be more than happy to do some precise backup/export, ideally all data (products with pictures, orders, customers, shop settings) from current 6.5.2 and load/import them into fresh new 7.4.x.

Unfortunately I dont know about any help/tool to properly “migrate” the data to be accepted by fresh new installation.

Summary: oxid 6.2.3 was running smooth under php 7.4.24 + mysql 5.7.35. I was able to upgrade to oxid 6.5.2 as a starting point for OXID 7.0 migration. Switched php to temporary version 8.1.31 to help with further migration/update to 7.0, staying under mysql 5.7.35 still to swap for 8.4.10 later (it was complete disaster otherwise).

Unfortunately too many issues and roolbacks before miracle happened and running 7.0.4 now. Most probably thanks to champ in previous thread who pointed out there is a big bug in 7.0.0 with new Theme, keep failing me into Maintenance Mode all the time without success.
Who should know it is fine to move forward with 7.0.0 when the only result is Maintenance Mode…? Who should have known about 7.0.0 bug as not documented and not mentioned either 7.0.0 should be skipped or temporary Maintenace Mode should be accepted before reaching 7.0.4?

Under 7.0.4 I had to manually enable new default Apex Theme, why as only one theme as Flow/Wave not supported anymore?
Bad formatting of pages, all prices zeroed (although properly existing in DB), plus only some pictures presented - only under product page and only some of them but nowhere else, assuming new theme wants to access them under different resolution folder with “w” in name based on path as I was able to find. Some convert needed? Why not covered properly by composer or oxid core automatically?

For sure again I dont know what to do with it, although I tried to follow precisely the documentation.

As a last attempt when being completely wasted and frustrated again after couple of more days, I tried to swap php for my final version for now = 8.3.31 and tried to move oxid from 7.0.4 towards 7.4 with Content Media Bundle 9. Again I followed the documentation, eshop administration now saying 7.4.0 but still eshop didnt generate properly new images, although sources still existing in master folder.

Even if I am able to somehow fix this formatting and prices and pictures although I dont know how and why this happened while instructions were followed, I am still unsure how to properly switch then mysql 5.7.35 towards new final for now 8.4.10

And why all this pain? Again, because there is nothing like some easy tool to help migrate all configs and user data from old 6.5.2 towards fresh empty installation of 7.4.0, no matter if in one or multiple working steps.

You mentioned General Export in oxid - but this is more funny feature than useful tool. It is very limited, mainly for Products. Where are at least pictures links? And orders and customers you mentioned? Not counting eshop settings, CMS pages, cathegories, everything else.

Either you are joking or you use some super guru method not described in upgrade options Documentation or I really dont know how you can export/import it all without breaking anything and just move configs and all data with all pictures relations into brand new 7.4.0 running directly using latest php and mysql.
Would you think I would suffer here so much if anything like this is possible?

I dont need any special modules, the very basic core is enough for me as it always was.

As mentioned, I never faced such problematic migrations taking long days without final success.

Other projects are either having precise bulletproof upgrade/migration steps or even better - each version can upgrade only to safe next version where all necessary edits and improvements are being done in background and bringing the whole project towards latest standards in several steps, ensuring in the end all data are well migrated and stay intact.

OXID in comparison? Just plain texts in Documentation like “we dont support this”, “we deprecated this”, “this is no longer valid and obsolete”…

Why the heck there cant be some smart logical roadmap documented so migration can be done fully using composer or other tool, especially when using the standard Core features only?

Why is composer telling me about deprecated features I should remove manually? Why it is not automatically swapped and removed, e.g. upon Y/N (if necessary) during composer running update?

Because in the end, I really dont care if the theme is Wave/Flow/Apex, I dont care about Symphony version or if swapped for Twyg and reasons for this.
For me the main goal is to have working latest version of eshop of course and to continue where it was under 6.5.2 and fully working with continuos data integrity and no php errors. Nothing more, nothing less. Who is more advanced and using own templates or modules should know much more about relations and can guide composer/update his own way as needed.

All and all, as mentioned, it is very painful as too many changes done in Core in only one version jump, of course causing serious issues.
Not speaking about relations to versions of composer, php, mysql and other components.

Can you see how this is unfortunately not working at all?

Please link me or tell me how to export EVERYTHING from 6.5.2 and successfully import it into fresh 7.4.0 and I am more than happy to do it.
Otherwise, based on Documentation, I believe the only way is current painful journey through several versions with many changes, making it very likely to cause too many issues.
Or do you think I am happy to spend here days without moving myself to finish?
Very happy to backup 6.5.2 completely and restore into brand new 7.4.0 what could further help to clean the project a bit from old traces caused over time and over many previous versions.

Thank you in advance.

4

Spending several days stuck on an update is a nuisance. But there are a few things I’d put in a different light.

First of all, I’m surprised you didn’t go straight to 7.5 but opted for 7.4 instead. Reading about the installation of 7.0.0, I suspect you didn’t realize from the documentation that the version numbers are just examples. So you should actually refer to the most recent release notes. It’s actually quite normal not to go for the very oldest version, so 7.0.0, and then 7.0.3 instead of 7.0.4. This is actually a recurring theme throughout the whole story here, such as theme activation (including the fact that Wave theme still exists) or the choice of PHP and database version so that you don’t have to change too many things. The solution was actually already in the documentation throughout, but it was apparently overlooked or not read right to the end.

Incidentally, how to switch from MySQL 5.7 to 8.4 is really a question for your hosting provider or server admin; it has nothing to do with OXID itself.

As for the image links, these are generated automatically from the master image as soon as they’re needed. There’s nothing to export there; it’s simply runtime logic. If they don’t appear, it’s usually down to a permissions or path issue, or a shop malfunction, not a missing feature. It would be worth taking a look at the logs.

As for your suggestion to simply back up 6.5.2 and import it into a clean 7.5 installation, to be honest, I reckon the old remnants you’re talking about are probably the very cause of your problems, not just in the code but possibly also directly in the database itself (orphaned entries, odd legacy issues from a structure that’s grown over the years, which get dragged along with every migration step). Experience shows that a clean, unmodified standard shop without modules can be run through several versions in half an hour, without any drama at all. The fact that it’s taking you days is actually proof that there are more issues to sort out than just the core, and no modules would suggest otherwise.

As for a tool to handle the entire migration, you were already referred in the previous post to the OXID platform, where partners offer solutions specifically designed for this sort of thing (data migration, moving to fresh installations, etc.).

And to be perfectly honest, as a forum user, my motivation to help drops quite quickly when a long, emotional outpouring is followed by very little useful technical information (no log, no link, no specific error messages) and when suggestions, such as the reference to the solutionhub solutions in the previous post, are simply overlooked or ignored, and replies are in turn met with yet another long, emotional outpouring. That comes across more as venting frustration than as an attempt to solve the problem together, and a forum like this isn’t really the right place for that.

It would also be helpful if you could post a link to the shop; then people could look at the image and pricing issues for themselves and, for example, trace the problem via the browser log or developer tools, rather than just guessing based on the description.

But what strikes me in general is this: many of your problems could probably have been avoided if you’d consistently checked the log as soon as something stopped working, rather than simply carrying on trying or switching versions. Your approach to Composer (selecting specific versions, understanding constraints, and interpreting error messages) also seems to be more trial and error than a methodical process. This isn’t a criticism at all; not everyone does this sort of thing every day, but to be honest, given the amount of time you’ve already invested here and the frustration this is clearly causing, it would probably work out cheaper in the long run and definitely be quicker to find an OXID partner or an agency with experience in exactly this sort of migration. They know the pitfalls, know where to look in the log, and would probably deliver what you’ve been struggling with here for x days in a fraction of the time.

By the way, you still haven’t changed the thread title :wink: I think it would make sense, because when you click on ‘Many problems with oxid eshop 2,’ you don’t really know what it’s specifically about.

5

I am sorry if it sounds emotional. But yes, it is very frustrating, especially compared to any other project I was facing so far.

Now I am deciding if to continue this big pain or if I can export at least products with prices and pictures relations and import it into either brand new latest oxid 7.x or alternative eshop service built from zero.

I am currently busy with other tasks, but I plan to run new containers to compare options in parallel. In the end, although I would prefer to stay with oxid, if alternative will be less painful, probably it is time to move after 10+ years from oxid to well refined modern painless solution. Because it is nice to follow “metodical process” and burn endless nights with stuff which should work almost “out of the box”, but it doesnt because “metodical process” was completely not followed by devs while doing many big complex changes at once, what is simply burying oxid in my opinion.

Simple tool to migrate properly? Divide big changes among more separate steps instead of big bang? Standard approach for many other projects, right.

6

The zero prices and missing images usually point to something not migrating right during the upgrade rather than the whole thing being broken. Have you checked if theres a cache that needs clearing or if the product data actually came over in the database properly? Sometimes those show up as separate issues even when the upgrade technically completed.