Traumflug

For a PS 1.6 migration there's a migration module which does something similar: https://thirtybees.com/migrate-from-prestashop/

Apparently these modules installed files outside their own folder. Maybe even modified existing ones. Which makes rolling back hard, perhaps impossible. I'd try it this way: Make a database backup with phpMyAdmin. Back up the img/ folder. Delete the database. Start over with a virgin installation, no demo products, same database name. Restore database and img/ folder. Recreate thumbnails, .htaccess and robots.txt.

Here are seven of them, all current and three of them supporting PayPal (one through the standard PayPal module): https://addons.prestashop.com/en/627-recurring-payment-subscription

30bz doesn’t even know what OS the system will run on – Linux? BSD? Windows? OSX? It doesn't matter, 30bz has zero touching points with the operating system. Who says a server will be running Apache or MySQL? [...] Who knows which version any of this will be? The server knows and sends this information with every page request. PHP knows it, too, see phpinfo() Corrupt cache, a cache that needs to be manually refreshed Yet another reason to cut down this cache mess. This discussion pretty clearly shows why setting up a shop is considered to be hard. People expect it to be hard, a self fulfilling prophecy. Accordingly these people have zero vision on how to make it a couple-of-clicks experience. It clearly can be done.

You knew which hardware you were willing to support and you had control over the codebase that would be run on that hardware. That's exactly what 30bz has, too. Shopify but it’s because they have done an incredible job. Shopify did what a thirty bees user should be able to do within an hour. I simply don't buy this "it's all too complicated". PHP has a well defined API, Apache has the same, as has MySQL. Many users demonstrate here that setting up a shop can be done in short time. So let's make this even easier!

Some hosts don’t offer some cache types, as @MockoB mentioned. Some hosts offer a cache type but only in an older version. Such stuff can be detected automatically. No need to put that burden onto the user. Sometimes a module will conflict with a certain type of caching as well This is a problem the module developer should deal with. Again, no need to bother the user with it. you guys could do this because you had complete control over the system. Actually we didn't. This software runs on some 50 distinct controllers, including different architectures. Still this strategy worked out, because what makes a software faster on a 8-bit architecture makes it usually faster on a 32-bit architecture, too. If not, code detects this and offers distinct code paths for both. OK, I'll stop now. Web software was always complicated in the details, so it'll take time until users get used to simplicity.

This flexibility isn't of much point if there's no help to decide which settings fit best. Accordingly one needs some performance measurement system. I'm not aware of one other than turning on profiling, playing around and looking at the numbers. If some caching system always improves performance, there's not much point in allowing to turn it off individually. That's why I think there should be a single on/off button. Developers can test each cache strategy and do the individual decision for or against a system at development time already. SaaS providers can do it, too, after all. If there are decisions which depend on the hardware in use, such tests can be run automated. Like running some phantomjs measurement for an hour or two, spitting out a configuration file with the best combination found. At this point I want to emphasize that I do not point fingers to developers. No mistakes happened. The situation is just not completed and what I write here hopefully helps a bit to find a sensible guideline for future developments. To give an example from embedded development (3D printer controller): early rule of thumb there was to make the binary as small as possible. Not because "disk" space is limited, but because each instruction has to be loaded and executed, which costs time. This alone brought performance some 20% over the competition, which uses all kinds of tricks (like writing in assembler) to meet buzzword performance improvements. Next step was to introduce a performance measurement system. A simulator running the firmware on a PC. Now we could measure the number of clock cycles between two waypoints and had standard tests to get comparable results. This way we could try and experiment, shaving off microsecond by microsecond of what we had already. And had hard facts on which variant of code performed better, instead of guessing. Each commit got a performance report. Developers enjoyed to experiment and came out with things like this: "look, if I multiply before the division, it's 0.2% faster!" And these 0.2% happened often, eventually added up. End result is a 3D printer firmware not 20%, but 100% faster, 15% the binary size of these competitors and known to have the easiest readable code.

Thanks for the explanation, @moy2010. There's also a "CCC-cache" and 30bz code has kind of an internal caching system, too. Quite often, database queries are stored in some cache file and retrieved from there on the next read. My gut feeling says there are so many cache mechanisms that handling all of them is slower than going without them. For example, what is the point of a database cache? A DB server should know best how to use available RAM for maximum performance. Accordingly, instructing the DB server to grab more RAM is better than putting a caching system on top of it. Also this Smarty cache. It's output is PHP, which is yet again cached as OPcache. And a third time if it's a full page cache hit. @MockoB: I think all this caching stuff should melt down into a single on/off button. Perhaps also a selector on where to apply the full page cache, but that's it. Also, to make extra sure a price change is recognized, simply clear the cache. All this said, cleaning all these caching mechanisms is likely a lot of work and I can almost hear all the complaints about "30bz doesn't support caching!, it's slow!" :-)

mdekker could you solve this? I'm not mdekker, but I think one should ask module authors to fix their modules.

Placing the support email address more prominently? Email does everything a ticketing system needs (answer goes to the customer only, customer gets notified, history is preserved) and on top, a new customer doesn't have to create an account. One can even place mailto: links which pre-fill that email, e.g. with a ticket number and/or the currently visited page.

It's a one-page checkout like in having only a single page. Cart at the top, then addresses, carriers, payment options. Only caveat I can see is that one has indeed to save the address before one can choose a payment option. That's somewhat unavoidable because one can't make a contract (binding prices and processing times) without knowing about the shipping address first. PS 1.7's "one" page checkout suffers the same; the later steps can't be opened before the first two are filled and saved.

I wonder all the time why people ask for a one-page checkout all the time. There is one, right in thirty bees, standard installation. Just enable it in Backoffice -> Preferences -> Orders -> General. Works just nicely.

I set up new shops every now and then, they all work. But I also have no extra files appearing out of nothing. Perhaps the trick is to set up a standard shop first. Then test this. Only then it's time to try with additional modules, one at a time. Modules are a tricky business, they can break things easily.

Closer :-) Having no carrier leads to having no DB table with carriers at all. There should be such a table, but an empty one. As said, creating a carrier should work around this problem. Even if this carrier isn't used. Another one: the backtrace at the bottom of the exception report indicates you have a file override/classes/Hook.php and the exception happens in there. This file isn't part of the standard installation. Where does it come from? Are there any non-standard modules installed already?

My bad, I misinterpreted what's going on. Accessing a shop from a "wrong" URL shouldn't cause an exception, of course. It should redirect to the "correct" shop domain - even if this doesn't exist. Getting a login screen means accessing backoffice basically works. Login screen is one of the backoffice pages, after all. What happens if you try to log in? when I try to restore the database backup gives error Looks like this should be fixed, first. One can't work with a database restored only 50%, of course.

After moving or copying a shop one has to set the new domains and/or the new URI. Backoffice -> Preferences -> SEO & URLs -> Set shop URLs. Backoffice should be reachable on any domain.

Are your products marked as being virtual products? If yes, I'd try to set up a dummy carrier. Maybe 30bz trips over an empty carrier list (which would be a bug).

I add FontAwesome by CDN. Come on. 30bz comes with no less than 3 font-awesomes (admin/themes/default/sass/vendor, themes/community-theme-default/sass/vendor and modules/themeconfigurator/views/css/font) already and that's still not enough for you? Haha :-)

@wakabayashi is right, one needs to adjust these three fields in SEO & URLs to match the actual host. Backoffice has no such restriction, it loads from any domain or folder. There are also commits pending to allow setting these fields to *automatic*. Yet more, there are commits moving this setting into a regular file, so they can be changed on the command line easily (e.g. by an upload script). I hope I can get back to these before too long, currently I'm still covered with support for PS 1.7 themes.

Applying this change to config/defines.inc.php ( = turning on debug mode) will make the error message visible: diff /* Debug only */ if (!defined('_PS_MODE_DEV_')) { -define('_PS_MODE_DEV_', false); +define('_PS_MODE_DEV_', true); } /* Compatibility warning */

No need to make headache about this bug. It's a visual glitch, only. The module manager received some changes for v1.0.1 and apparently these texts are no longer interpreted as HTML, but as plain text. I'm just not sure which way they should be interpreted. Interpreting them as HTML allows nice things like bold text, but also ugly things like embedded JavaScript pulling your friendly next trojan.

I've opened an issue for this: https://github.com/thirtybees/thirtybees/issues/242

This ' is what's written into the module's config.xml. Changing it to a ' there fixes the problem.

Uh, this jgnbklef... should be the domain. U-oh. I'd delete them and keep an eye on when they reappear. Only bugs with a known set of steps to reproduce them can be fixed.

If bold text means the current setting, I'd change PHP to 7.0. PHP 7.1 is known to be not (yet) as stable as it should be.