Jump to content
thirty bees forum

Traumflug

Members
  • Posts

    1,665
  • Joined

  • Last visited

  • Days Won

    82

Posts posted by Traumflug

  1. 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 :-)

  2. 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".

  3. 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.

  4. 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

  5. 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.

  6. 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.

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

  8. 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().

  9. 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:

    0_1510311020629_Bildschirmfoto von »2017-11-10 11-44-42«.png - ~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.

  10. 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.

×
×
  • Create New...