Traumflug

But i don’t understand the logic to deleted and recreated. the reason why. It's the simplest way to do an update. Such updates happen rarely, so there's no need for performance optimization. For Tags I’ve found another logic to develop the solution Code, please! :relaxed: Ideally as a pull request, but patches uploaded here are also welcome.

No need to feel sorry, multiple reports put more emphasis on the matter and confirm the first report. In the Ubuntu tracker, bugs with duplicates even get bonus points.

I create a standard “tb in a box”, back it up, and restore it in another domain. Simsalabim, working Yes, absolutely!

People usually write code which fits their needs. They have no magic crystal ball to find out which other uses one could come up with in the future. The code in question was written in 7/2015 (reformatted later). Now it's 2017 and you found such an additional use, so this code apparently needs a review. If you can come up with better code, not breaking previous usage, I'm pretty sure it can be accepted for thirty bees 1.1.0.

In multistore this applies to the first shop. All defined domains load their related shop, all other domains load the first shop. Maybe this feature makes using multistore obsolete in some cases, because defining multiple URLs just to make one shop accessible from multiple domains is no longer necessary.

P.S.: another use case is when copying a shop from one domain to another. No need to adjust shop URLs set to automatic, then.

Doing my first steps with PrestaShop worked pretty well. Went to http://localhost/, ran the installer, eventually started editing the theme. Ah, right, mobile users! Picked the phone to see how it looks there, connected to my desktop and ... u-oh, "This page can't be opened, because Safari can't find the server" Bummer. What happened? Well, at installation time, domain name was localhost. Installer picked this up. Shop software insists on this domain and redirects to it, even if the shop is accessed from another address. Accordingly, http://mydesktop.local gets redirected to http://localhost, which is an entirely different host on the phone, of course. A long googling session later I learned how to fix this misalignment, still I couldn't resist to teach this shop software proper manners. Domain *automatic* was born. This is how it looks in Backoffice -> Preferences -> SEO & URLs: Having it enabled means that thirty bees will no longer try to redirect traffic just because the domain is "wrong". It'll just proceed. It's turned off and works as before when an actual domain name is entered in these fields. What do you think about this feature? Useful? Might it break other use cases? Thanks for your comments. Related Github pull request: https://github.com/thirtybees/thirtybees/pull/250, it'll go into thirty bees 1.1.0, then.

Is PageCache in this class index? The section should look like this: php 'PageCache' => array ( 'path' => '', 'type' => 'class', 'override' => false, ), 'PageCacheCore' => array ( 'path' => 'classes/PageCache.php', 'type' => 'class', 'override' => false, ),

Excellent! Let's assume for now these error messages are a result of you upgrading the database in this unusual way :-)

PageCache::flush() exists: https://github.com/thirtybees/thirtybees/blob/1.0.x/classes/PageCache.php#L173 Are there overrides involved? cache/class_index.php deleted (will be re-built automatically) ?

Line 286 in AjaxProcessor.php is this: php $this->nextQuickInfo[] = sprintf($this->l('Files will be saved to %s and %s'), $this->getCoreFilePath()); Two %s and just one argument indeed look like a bug.

Sounds pretty similar to this one: https://forum.thirtybees.com/topic/340/upgrade-error-500

Dataset is obviously the data which is subject for searching. As a coarse estimate one can use the size of the uncompressed database backup file.

Maybe there are some extra steps required to get these rules into effect. Instead of investigating what this could be it's probably easier to apply the patch here: https://forum.thirtybees.com/topic/320/problem-saving-seo-url-routes/3 Use a generic text editor (Word is the wrong tool), open file controllers/admin/AdminMetaController.php, find text addFieldRoute(, then 'type' => 'text', then change this 'text' to 'textLang' and save the file. On success there will be a small menu for selecting the language under each of these rewrite rule fields. Modify the rule(s) to your likings, do the same for each language, click 'Save', then 'Regenerate URLs'. This should do the trick.

Your shop is running, where's the problem?

Eeeek. Overrides. Source of trouble. Usually these overrides are made for PrestaShop. Thirty bees changed quite a bit under the hood, so no surprise if PS overrides don't work on 30bz.

See https://forum.thirtybees.com/topic/320/problem-saving-seo-url-routes: The table to edit for manual tweaks isn't configuration, but configuration_lang. Rewrite settings are language-aware, so one has to change the value for each language. Distinct values for different languages are perfectly possible. While this currently isn't possible in backoffice, a fix is provided for 1.0.2.

Done: https://github.com/thirtybees/thirtybees/pull/249 A couple of things I learned along the way: Language-aware rewrite rules are a pretty young, 30bz-only feature. They do work, switching languages on a product page changes it's URL as appropriate. Entries in configuration_lang aren't self-sufficient. They're kind of an add-on to an entry in configuration. Installer does indeed create ..._lang entries, my installed DB was too old. @braffas' patch is spot-on. Thank you.

Code snippets I found are a bit contradicting. Default values ignore the language. Installer installs apparently empty fields in configuration. Other code snippets, the one you found, too, handle it as language dependent. This raises the question whether language dependent rewrite rules can work and if yes, whether they're a wanted feature. Having language dependent rewrite rules easily opens a can of worms, e.g. just switching the language might lead to a 404 page.

Funny: without the patch, these values aren't stored at all. The shown values are the default ones.

Thanks for providing this patch, @braffas. I can confirm this misbehavior. While this change indeed appears to work, I think it's the wrong solution. This makes rewriting rules language dependent, rules are then stored in table tb_configuration_lang instead of tb_configuration. I don't think setting different rules for distinct languages works. I'm currently searching for a better solution.

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.