[Tutorial: How to migrate from ps 1.6 to thirty bees]

:thumbsuptone4: for doing such a video! :thumbsuptone4: for showing how to clone a shop and for working on that clone! :thumbsup_tone4: for the module doing the migration so seamlessly!

To those who have a clone already or want to try on a test installation: start at 10:20 in the video.

[Split Payments]

That said, as a good merchant I should have offered you to implement all four features, take the cash for all of them and implement only the one needed thing.

[Split Payments]

Right. So you don't want an entire module, but enhance the existing module to allow subscriptions as well. Split payments are (hopefully) transparent to the user, so no module change required. Invoices can be done by 30bz, so no change required either.

Entirely different perspective for a developer.

[Split Payments]

@Havouza

now I only need a programmer to make the module

https://docs.payza.com/reference#prestashop

[Tags ID are incremented each time a product is modified]

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.

[Error when upgrading from 1.0.0 to 1.0.1]

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.

[Request For Comment: automatic domain feature]

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

Yes, absolutely!

[Tags ID are incremented each time a product is modified]

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.

[Request For Comment: automatic domain feature]

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.

[Request For Comment: automatic domain feature]

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.

[Request For Comment: automatic domain feature]

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.

[Delete Cache]

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, ),

[Url changed after migration]

Excellent!

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

[Delete Cache]

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) ?

[Upgrade Error 500]

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.

[Error when upgrading from 1.0.0 to 1.0.1]

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

[Let's talk about Search!]

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.

[Url changed after migration]

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.

[Perhaps it it so.....]

Your shop is running, where's the problem?

[Enable Profiling - Override functions are undefined & getting 500]

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.

[Url changed after migration]

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.

[Problem saving SEO url routes]

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.

[Problem saving SEO url routes]

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.

[Problem saving SEO url routes]

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

[Problem saving SEO url routes]

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.