Traumflug

Eigentlich wollte ich gestern diese Macke im AEUC-Modul angehen, bei der irgendwie doppelte Texte erscheinen. Oder sowas Ähnliches. Selber habe ich das noch nie gesehen und ich kann es auch nicht reproduzieren, siehe https://github.com/thirtybees/thirtybees/issues/104#issuecomment-346155268 Deswegen wäre es grossartig, wenn mir jemand helfen könnte, diese Macke ans Tageslicht zu befördern. Man kann nur Macken beheben, die sich auch reproduzieren lassen. Es braucht wohl ein paar mehr Details, wie man zu diesen doppelten Texten kommt. Besten Dank für die Hilfe. Bildschirmfotos, Schritt-für-Schritt-Anleitungen für einen frisch installierten Shop, alles ist willkommen. Reproduzierbarkeit muss her. Ähm, nicht bei Euch, sondern bei mir :-)

I think it depends a bit on what the goal of this one-domain-per-country strategy is. It can be used to adjust offerings to local needs. To get this, there's multishop. As far as a quick research goes, language settings are for all shops together, but one can always choose browser's default language. Another one might be to deal with customer habits. They're simply used to type "es.myshop.com" over "myshop.es". In that case, multishop comes to the rescue, too, because it allows to set up many URLs for a single shop. They all get redirected to the main URL, then. Third possible choice is to establish a couple of .htaccess rules, redirecting from "es.myshop.com" to "myshop.com/es".

For the non-Europeans among us, SEPA is "Single Euro Payments Area" and their bank wires work across the entire Euro-Zone, several countries, usually for free (or almost free, like € 0.30). Just this morning I found this announcement (in German language): https://www.heise.de/newsticker/meldung/Instant-Payments-Startschuss-fuer-schnellere-SEPA-Ueberweisungen-3897021.html Very good news for merchants, IMHO. There's now a new form of bank wire which gets completed in not the usual day, but in a maximum time of 15 seconds. 15 seconds? Works currently not everywhere (both, sending and receiving bank have to participate), but this also means bank wires likely get a boost. Because it's reliable, because it's cheap and now also because it's fast. Bye bye money transfer fees.

Will it get faster with caching enabled? Easiest way to find this out would be to turn caching on. Obviously.

Glad to see you got this solved, @Boyd. It's not too surprising that even short passwords expose the problem, because passwords are stored encrypted and many encryption mechanisms generate an encrypted string of constant length. All the encryption stuff is in need of an overhaul anyways, because PHP 7.1 now officially deprecated the mcrypt extension, the current default encryption mechanism. And there are three different encryption mechanisms while two are sufficient (a non-reversible one for passwords and a reversible one for cookies and exception reports). This is tracked here: https://github.com/thirtybees/thirtybees/issues/386

Thanks for the report, @Boyd. Moved this to the bug reports section as it's obviously a bug. Please look at Backoffice -> Advanced Parameters -> Performance, there's a panel "Ciphering". What is set ciphering to (PHP Encryption or Rijndael or BlowFish)? Also, if you could share the password used it'd help debugging this.

As @mdekker mentioned in the Github issue, such phone numbers potentially get sent to many places, like carriers, payment processors or similar. Shaping the number would avoid it becoming stuck later. With 'shaping' I mean things like replacing all the various whitespace types with an ordinary space character, replacing various dash types with the ordinary minus sign and such stuff.

Looking at this discussion I think there is an actual demand, so I opened an enhancement issue for this, mentioning @dynambee's (partial) solution: https://github.com/thirtybees/thirtybees/issues/397

@daokakao why not to bind your MX record For this to happen, a user whould have to understand that an "MX record" actually exists, what it does and how it's changed. I don't think this is the level of expertise 30bz wants to be mandatory for running a shop. There has to be an easier solution ... which doesn't stop experts from doing what you described, of course.

https://github.com/thirtybees/thirtybees/issues/396

inadvertently included a trailing CR, LF, tab, tripping over such a situation would be a bug.

For debugging you can change this validation method to this: ```php public static function isPhoneNumber($number) { if (!pregmatch('/^[+0-9. ()-]*$/', $number)) { fileputcontents(PSROOTDIR.'/config/phonenumbers-failed', varexport($number, true)."\n", FILE_APPEND); } return true; } ``` This will create a file config/phonenumbers-failed and list all the failed phone numbers inside there. Still report success in any case.

See the green menu item? That's where one marks a thread as solved. Your menu should be a bit shorter, but the green item should be there. BTW, the menu item below the green one is for making a question topic a normal one and vice versa.

I've opened a Github issue for this: https://github.com/thirtybees/community-theme-default/issues/30 Broken appearance looks, well, broken.

Shell is for people who know what they are doing. Shell is for people willing to learn how things work. :-) Maybe it looks like I can do Voodoo there, but all this was learned step by step, by reading manual pages, by trying and iterating.

The migration module didn't work for you, right? Simply replacing code files doesn't work for the reason you see. What you can try is to do a fresh thirty bees shop installation (into a subfolder), using a fresh database. This should give a working shop. To recover all the stuff from the previous shop, open config/settings.inc.php in both, new and old shop, then transfer database settings (those beginning with _DB_...) from old to new. Having this done, the new shop should show all the products from the old shop ... except pictures. To get pictures, too, move/copy img/p from the old to the new shop, replacing the previous folder there. Chances to get a working shop then are good. One can move a shop from one folder to another folder by moving all the files, but one also has to go to Backoffice -> Preferences -> SEO & URLs -> Set Shop URLs and adjust Base URI there. All this said, any chances to get the migration module debugged? What's going wrong after uninstalling custom modules?

One addition for db.php: The function executeS() contains the Tools::displayError() too. It too should be replaced with echo. Done: https://github.com/thirtybees/tbupdater/pull/11/commits/c7e7f29a3b2024edaf16886120e80520a2a1b6f2 Choosed the die() route, because in all these places, Tools::displayError() was followed by an exit().

Opened a Github issue for this, too: https://github.com/thirtybees/thirtybees/issues/394 As moving a post apparently leaves no trail in the original spot behind: ping @Saha :-)

Moved this to the bug reports section as it's obviously a bug report.

Sorry for the noise above. After my marketing allergy calmed down, let me try to do elaborate this a bit more seriously. Web space required is about 1 GB plus all the pictures. Which means, the usual 10 GB or 20 GB offerings are plenty for small shops. Pages loading fast is certainly a bonus. And then look at Amazon, arbitrary product page: - ~4 seconds for the first visible content, 25 seconds until the page calms down. My personal conclusion with Amazon's success in mind: customers prefer good offerings, nice pictures, good descriptions over a few milliseconds of faster loading. - One thing peeking out in the above picture: it reads "unmetered web traffic", but it also reads "10'000 visits/month". Counting visits is obviously metering, and 10'000/month is just 333/day. I take it's page visits, not shop visits, so every page loaded counts. Think of search engines crawling the shop, think of customers looking at all your goodies over and over again, being undecided. - The picture also reads "unlimited emails". Lesley says they have no email at all. Email is crucial, customers can't order without it. - Changing plans is nothing special, I think pretty much all hosters offer this. - Server market is with high competition. Nobody can donate something, but also nobody can ask for unjustified high prices. Good for merchants, chances to waste substantial amounts of money are low. - Moving from one hoster to another is fairly easy in case it doesn't work out as expected. Because all this is a bit overwhelming I tend to simplify such choices: look at the key features (web space, DB, email), then at how long it takes to cancel the contract and if that's short enough, simply go ahead. Working on good product presentation is much more important than saving a dollar or two on server hosting.

One can switch from monoshop to multishop any time. A monoshop is essentially a multishop with just one shop defined. That said, multishops are made with similar offerings in mind. If shop offerings are totally unrelated it might be a better idea to run two independent shops. Can be done with a single host easily, just put them into separate subdirectories and point your domain name server to each of them.

What I mean is that a posting like yours would make me go away immediately. But feel free to continue. It's an open forum.

Confirmed. Opened an issue to track this: https://github.com/thirtybees/thirtybees/issues/393

OMG, one round of marketing slang. You will be actually saving a few $$$ while hosting with us. Yes. Most savings when not going with "us". SCNR

I've opened a bug report for this issue to not forget it: https://github.com/thirtybees/referralprogram/issues/1