Traumflug

Confirmed to be broken. HTML looks like this: generic <link rel="icon" type="image/vnd.microsoft.icon" href="/www.reprap-diy.com/shop/img/favicon.ico?1493478356"> <link rel="shortcut icon" type="image/x-icon" href="/www.reprap-diy.com/shop/img/favicon.ico?1493478356"> where www.reprap-diy.com/shop is the shop_uri (domain is 'localhost'). Also four lines of HTML for favicons in various sizes. Looking into apache's log, favicon.ico gets requested and delivered, but apparently by a picture with this question mark instead of the expected one. A request for /www.reprap-diy.com/shop/img/favicon_144.png is answered with 404.

The same way you do it with PrestaShop: make a DB backup, copy files over and restore the DB there. Doing both migrations at the same time isn't a good idea.

Here are detailed instructions: https://thirtybees.com/migrate-from-prestashop/

@Webshoptime, you install the 30bz migration module in your PS 1.6 shop, then do the upgrade and end up with a 30bz shop.

A Git repo doesn't stop you from doing an upgrade. Just upgrade and commit all the changes. Before doing so I'd make a DB backup and commit this backup file to allow rolling back later. A git history isn't of much worth if you don't have a matching database. For myself I use a Git repo filled with distributed files. Like generic 1.0.0---B-----1.0.1---B-----1.0.2---B----... \ \ \ \ \ \--L''--L''--L''--L''--L'' <= life site \ \ ---L'---L'---L'---L'---L' \--L----L----L----L----L Where: 1.0.0, 1.0.1, 1.0.2, ... unmodified installations made from distribution ZIP, then upgraded for each release. B = database backup, backup file committed into the repo. L = local code changes For each release I create a new branch on the previous unmodified installation, upgrade, then make a copy of the branch with previous local changes and rebase that to the new release. Sometimes a straight rebase is too complex, then I cherry-pick commit by commit from the previous branch, adjusting them as needed. All this requires to understand a Git repo not as a backup tool or dump yard, but as a tool allowing to build code like with Lego bricks (one brick = one commit), allowing to copy and move commits as needed. Reading up on 'topic branches' and on how to rebase them is a good starter. P.S.: 1.0.2 isn't released, yet. I put it into the graph for illustration purposes.

Confirmed.

Quite possible you saw it, module 'beesblog' had some short lived appearances already. No hallucinations :-)

The one for the main repo appears to be fine and on the third try, Travis CI apparently works, too.

Yes. Same with each of the 84 modules.

Works nicely and with decent speed from Germany. These pictures in the immediate search result are certainly a good idea!

Other than wit PS 1.6, the theme is a separate module. Try something like this: sh $ cd themes/community-theme-default/ $ git status $ git add . $ git commit If you want to prepare for a pull request, you have to work of a personal clone, too, just like with the main repo. As we're on the topic: updating all submodules goes like this (from the main repo, takes something like a minute): sh git submodule update --init --remote --rebase

All the better, @ssimard ! @dynambee wrote about this lack of functionality in the opening post, so I didn't even try. Now I tried and see this working in TB, too.

FWIW, PS 1.7 does show results as one types, so one option would be to grab code from there. (Theme is Classic with heavily modified CSS)

Is this topic solved? Please mark it as solved then, @atolodas. It's behind these three dots to the right of 'reply' and 'quote'. P.S.: actually I was wrong about this three-dot hamburger menu. Marking topics as resolved is in 'Topic Tools', rightmost in the series of buttons at the bottom of the first post.

The six remaining commits were accepted and are now on Git master. Thanks, @mdekker.

All 24 commits of mine were just moved to Git master. Thanks, @mdekker and thanks, @Havouza, for testing it.

If you wonder whether it's normal to have a couple of commits on top of the public ones: yes it is. My own development repo currently carries a stack of 69 commits on top of master. Most of them already provided as pull requests, but also simple ones like "turn on debug mode".

These are not unexpected. They're generated by one (or more) of the automatic upgrade processes built into 30bz (and PS). Either do a git checkout . to reset them or create a commit with all of them. Adding them to .gitignore isn't a good idea, because the English versions of these files are tracked in the main repository. At least at this point in time.

Just trying a provider won't reveal whether this provider looks into your data. But data is there and unencrypted, so he can. The same is true for any other provider, of course. Unless you rent/own a full server equipped with an encrypted filesystem and do server maintenance yourself.

Will melt down this work to align with what's now on master and pull request that tomorrow. Not everything lost :-)

I created a generator using PHP, I also removed the file from the Git repo, I implemented nice messages for developers, where the file doesn't exist. And of course I triple-check code before providing it to the public.

So I worked a full day for the trashcan. I thought it was clear that I'm working on this.

News :-) files.json: while it's tracked in the Git repo, it also gets updated when creating a package. You, @atolodas , apparently run a development installation. Only four files missing. With an installation made from a package it's much worse, 46 files missing :-) Wrote a PHP version of the file generator (currently used is a JavaScript variant) and it turns out, both generators generate the same (except for sorting). Updating files.json in a developer installation gives a perfectly fine validation. So, what the heck? The hint for the next step in this adventure game is here: files.json generated in a developer installation is 387 lines. The one generated for a package is 1261 lines. These two versions are expected to be the same. Going bicycling now and when coming back I'll put these puzzle pieces together.

The question arising is: when should this file receive updates? On every commit? On every bump of the release version? When creating a distribution package, creating this file on the fly?

This is simple: config/json/files.json is out of date. 4 files no longer exist, 221 files have changed. Not exactly a trust building situation :-)