Traumflug

Here's something wrong: require(/home//public_html /om/ thirtybees/config/config.inc.php) Each of the provided log entries shortens this part of the path differently. Code is very simple, nothing 30bz-specific: php require(dirname(__FILE__).'/config/config.inc.php'); Smells like there's something wrong with the PHP installation.

2nd An Nginx + apache server for a small store (1000 products) is viable For performance considerations, the number of page views counts a lot more than the number of products. If you're that keen on more performance, it'd be better to analyse the current state, first. There are plenty of tools, e.g. Firefox' built-in web developer toolbox, showing each file loaded and how long it takes. If you have shell access to the server, run 'top' for a while and watch how much it swaps. No/rare swapping -> RAM is sufficient. 4th is it feasible to put the store in normal web sites? Yes. Apache, PHP, database is sufficient.

Question is answered, marking as solved. Updater not working would be a bug.

Like this https://www.beautyandpleasure.co.uk/admin46336vcsa/index.php?controller=AdminLogin&token=f041618e6c8126e8bdeeb9924cf6c734&redirect=AdminDashboard Am I mistaken or are you asking for the login page ('controller=AdminLogin') ? I think the redirect thing is expected to be handled after calling the controller, not before it. If this link isn't handcrafted it might be a hint to a bug on the page generating this link.

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.