Pedalman

Hallo ich habe im Forum wie im Netz gesucht, aber nicht herausbekommen, ob TB 1.08 mit PHP 7.3 kompatibel ist. Wer weiß was? Markus?

Easy to use for all I need to do in TB is: " StoreCommander " They do not explictitly support TB at the moment but I use it since half a decade and with TB since 2 years and never had an issue. Support is fast. You find on their webpage a documentation about CSV im/export. You can buy software for a year and do not have to extend subscription. It is pretty solid and does not need constant upadates. Storecommander next to Datakick and Prestatools should speed up article maintanance enourmously.

And if we opt to update to bleeding edge I noticed that after doing it so once I could not do it again. In other words it seems once you are on the 0.x train file comparisson does not work anymore. At least in my case. I went the normal way from 1.0.7 to 1.0.8 with the Thirtybees updater. Then I used the coreupdater to patch up to bleeding edge (it was git status mid January since I had issues with Warehouse and hoped that they are solved by some commits from Petr). Since then I can not get the latest patches/commits it seems.

I am with the Pro version, too. It says that I have: You have latest version 2.0.4 of this module. Last check a few seconds ago I am asking wheather this is the really the latest Pro version since I have not found any auto 'login' options for customers to leave a review when they respond to the auto sent email. And moreover, I must say that I have a respond quoute from less than a 1% 😞 😞 😞 Not that my products are so bad but due to GDPR I thought that we we need a strikt consent option: Automation consent Consent type "Explicit consent is required" I do not know if we are allowed to use a less strikt consent policy on email reviews but at the moment really no one leaves a review 😞

I got a customer who wanted to order via paylater/pay via invoice but canceled the checkout. In a nutshell he did not order. Then he called us and wanted me to order. No problem I say but a problem occurs: I can not Add new address for the customer no matter I do. Under customers he appeard two times. I deleted the older entry after not being able to save adress data from back office since I hoped that might help. But it did not. I use latest 'bleeding edge' and can need help since I need to make this order for the customer.

I have a small change to my /js/admin.js that adds the function to mass download invoices. This is incredible helpful to me since I a have a tool running in the background of my OS that monitors my download folder for 'invoice.php'/'invoice.pdf' and send it directly to my printer and moves them then to another folder where my archive tool grabs them... If you change the file with the given lines of code you will get an additionl button in back office order at the bottom where the 'Action' button sits. $('body.adminorders .bulk-actions ul').append('<li><a href="#" id="downloadBulkSingle"><i class="icon-download"></i> Bulk InVOICE download</a></li>'); $('a#downloadBulkSingle').click(function(e){ e.preventDefault(); $('[name="orderBox[]"]:checked').each((i,e)=> $(e).parents('tr').find('a[href*="generateInvoicePDF"]').each((a,c) => c.click())); }); I inserted it into line 911.

Hello I use the Warehouse theme by Iquit and I want to make use of the JASON/LD module. I set up last week GoogleTagManager and thought that it might be also a good idea to get the named module with proper markup running. So, I am looking for some detailed documentation and setup instructions of the module. What I read is that I have to make sure that my template does not use any markup code. Well, Well... First I thought, easy, just look into product.tpl and category.tpl and delete anything that looks like markup. After recognizing the markup code tag I could also make a text search through the whole template folder... Then I thought, mh, may be some modules like cross-selling could also have some markup code implemented. You dig it, I have no real clue in this case what to do. So, perhaps some one could hint me the way?

There are at least two posts in the forum (technical problems is guess) that might be related to the 500er error. I use Warehouse too and ran into problems with saving 'content creator' module changes as pasting css into the theme editor form with TB1.0.8. I cloned my shop did a successfull test and repeated the same on my live shop yesterday and these two issues are gone. I did install the core updater module and updated to 'bleeding edge' version that reflects the latest GIT commits on the developing road so to speak. This I did since I believe Petr commited on Jan. 18th a fix relating to this issues. But I am just a merchant and the good ones here should give you the right hint. good luck PS: before trying what I did try to make changes in 'your' content creator module and to save them. Might be you get this 500er error and you know 😉

Hi Markus, you answered my question perfectly. Id did not know exactly what 'bleeding edge' reflects concerning the git commits. I did now the 1.0.x update on my live shop (yes, I am a bit of the risky type but that is also the reason why I am here since more than a year) and the problem is mostly gone. Saying mostly since before 1.0.8 I guess I could paste my css code nicely formatted into the corresponging form of my theme editor and it was saved like that. Now, all pre-formatting /beautifying is gone after saving and css code is 'pressed' into one long line in the form. But good news is that the escapes have gone and all works. Thank you very much

I think that the damn cool core updater module has a problem with a local install of Thirtybees under XAMPP Windows. Downloads calculated, 7632 files to download. (0.1 s) ERROR: Failed to download files with error: fatal: path not found: \admin1/ajax-tab.php

Ok, I did a test. I cloned my live shop and used successfully the coreupdater. I went from V1.08 to "bleeding edge". I suppose that is a version that reflects latest or the latest changes marked as stable in the devs git tree. Anyhow, I am no coder and have no clue about that. Fact is, now CSS code is the named form is shown correctly and the content editor is saving as used to. Great stuff! 🙂 Having a closer look I dig that on Jan. the 8th Petr made a fix public. So, here comes the big question. What shall I do as humble merchant? Shall I manuall update all files from GIT up to Jan. the 18th or so or shall I use the coreupdater in order to update the latest changes made public on GIT or wait for 1.09? I do not want to risk raise new errors in our shop that is for sure. Thank you

Custom CSS form in Warehouse template convuluted since TB V1.08 Hello this is really nasty. Since TB1.08 I would say since I do not know for certain my form that supports to save custom CSS code for the IQUIT Warehouse theme is convuluted. Escapes and so on mess all up. That needs an urgend fix since I can not work so 😕 Example: .columns-container {\r\n min-height: 600px;\r\n }\r\n /* check if good for mobil devices. made in order to not shrink content on some pages. Boris 02.2019#revws-home .btn-primary {background-color: #83C11F}/*startseiten 50% col banner*/\r\n \r\n #iqitcontentcreator .fullheight-banner {\r\n padding-right: 0px !important;\r\n }\r\n /*#order Moreover, the content creator module gives now an 500er error. Well, since the template isn't really developed anymore and worked for years this incompatibility must habe been created by Thirtybees I supppose. Anyhow, since I am not the only one with Warehouse here I hope a solution is ready?

Just asking into the blue: Did you change your statuses? Don't laugh but if there is no status set that tells the db that an order was sold than...

Just curious, what is the branch you are in? Please do not laugh, but if you are in a branch that heavily profits from Christmas business/sales then there you go. For me, it looks pretty much like that

As already said at the moment for the last 3 weeks paylater functionality was stalled (Mollie said officially they dropped support). All other payment option are said to have received their latest 'internal updates' 3 weeks ago and no one know when they might stop working. In a nutshell, at the moment all know problems are related to the webhook 'conversation' between Mollie <--> Thirtybees exclusively for the payment option paylater/Klarna. This worked for me today as stated. So, I am interested if anyone has received paylater orders in his shop the lasts days since I have not for 3 weeks except my own order (before we had daily sells via paylater). Thank you

Hello Petr, coming back to this. I reactivated Klarna paylater in live shop and did a test order. It went positively through after I created a customer with my original adress and entered my mobil phone number and birth date during checkout test (Klarna scoring test). With eyebrowses raised I had to notice that my order was accepted by Klarna and I had successfully bought on invoice/paylater and this was registered in my backoffice. In the log appears as it does in test mode: MollieWebhookModuleFrontController::processTransaction said: Received webhook request for order 1234/ transaction ord_1234 0 0x 0 08.02.2019 So, either Molly lowered their constraints on the PS/TB test or I was just lucky or what ever... I am happy since it might be something good and may be we can use Mollie in the future! Hower, before the problems started we had orders via pay later on a daily basis. My test order is now the first one for 3 weeks! What are the others experiencing here? Are you still with Mollie or any alternatives? Still receiving or freshly receiving Mollie / Klarna paylater orders?

In a nutshell: The TB version of the Mollie module hosted on Git is old (no one should use is since rounding errors etc. come with it as far as I can dig from the GIT code progress) The Prestashop version on Mollie hosted on GIT is in active development At the moment Mollie has stalled API communication for the payment option "pay later" by Klarna. We can expect to not be informed which payment option next is going to stall. Customer support told me all payment option won't get any updates any more for the TB version. I am happily willing to give access to Petr. Hope for the best

Thank you very much Petr and Lesley for your vigorate words on our perspective with Thirtybees. I know that all this arrousal came without any heads-up and no one heralded this. And you are absolutely right we have to face the actual situation and perhaps we (you 🙂 ) can workout a solution. I think the Mollie support is willing to help out, too, since we are dependent on PaymentServiceProviders as they are dependent on us. I for my part am willing to pay for the extra time needed in form of developer hours. I profit from Mollie, if it is working, and would have to spend many hours to find and integrate an alternative solution (where the same could happen). I do not know wheather there is now in this forum or in our blog a place where we can utter our top wishes that we merchants are willing or capable to pay for.

Edwin, that is what I wanted to hint at but didn't dare to say. First, I feel betrayed that TB differs to PS for any API. I have no idea of the technical side here but I am merchant and never was told that this could happen. First, that a PaymentServiceProvider or any other service can stop supporting Thirtybees cause TB's API is obviously in some ways different than the PS 1.6 one (and I hope that I am right that this was not consciously misused by someone who publicly said he does not want to be connected to TB anymore after he spend months of his life for the TB development) and second that as you point out correctly there is deadline for the PS API development. So, I am coming back to my question if there is a technical way to simulate any API? Could Thirtybees be this "open" so we will never fear to compatibility in this way or that we can get back access to Mollie etc? ********** I am not giving anyone at the moment the blame. But as said I am shocked that a service provider that claims to support Prestashop V1.6x can block Thirtybees. On the other hand I am shocked that the maintainers of the Mollie GIT claimed that for Thirtybees users there will be no problems since! Thirtybees is compatible: Am 03.11.2018 um 13:02 schrieb [email protected]: > > Dear Boris, > > I just recieved your message on my voicemail. Could you please inform me who provided you with my mobile phone number, as for it is not visible on our website? > > Concerning your question regarding thirty bees. The Mollie module is / should be compatible with thirty bees, because thirty bees is compatible with PS 1.6. > > You can find the repository here: > > https://github.com/mollie/PrestaShop > > We also set up a repository here (https://github.com/mollie/thirtybees) but it is not supported and will be removed in the near future. > > You can create an account at https://mollie.com and test the module on your development / staging environment (before placing it on your live shop) to see what it has to offer. It has many great features, a lot of different payment methods and Mollie offers very competitive pricing as well. > > Have a nice weekend. > > > Kind Regards, > > On behalf of Snowy Cat Software > > Mxxx. Diexxx

Hello I really appreciate that finally a nice theme for Thirtybees is being developed. Moreover I like we share the same rules of how a nice page has to look. Anyway since I need to spend more time on my business than adapting themes via CSS etc. to my suits I want you to ask if your theme might support a page builder like: https://www.leotheme.com/prestashop/prestashop-modules/699-ap-page-builder-prestashop-module.html I have not used that one since I am still with my adapted Warehoue theme but that module of Leo looks promising. Are you supporting directly the JSON Thirtybees module ?

UPDATE Bad, really bad news: Mollie (or Mr. Dekker and Mr. Diederiks ) do no more support Thirtybees. Even more, since V3.3.4 (the latest is V3.3.5) they even seem to block Thirtybees. Fact is that since mid of January 2019 the Mollie API stopped to inform ThirtyBees that an order made via "PayLater" / Klarna was successfully made. Customers were "authorized" to use the pay later service buut Mollie did not resend this data to the Thirtbees shop. The bad result is that we as merchant did not even know that we had a new order! That means also customers think they have successfully baught via pay later and are waiting for their shipment but all they get is if things go wrong a payment reminder from Klarna for products they never received. I am really, really angry now since I just get informed that Mollie stopped compatibility with Thirtybees for all payment options! That means, PayLater Klarna is broken since January and all other payment options won't get updates anymore 😞 I am just a merchant and since 8 years I had always trouble with payment providers. This is what I live from. I need working payment providers. But since Mr. Dekker started forking and adjusting the official PayPal module for Thirtybees two years ago this never worked flawlessly. That were many problems with it and caused unneccessary trouble for the merchant. Maybe that the problems (mostly timing problems of the PayPal / sho API) were also existent for the official Prestashop PayPal modul but I doubt so. This is the same now for the Mollie module. They said no problem at all. Thirtybees is compatible with Prestashop so we can stop developing the TB module since you can use the PS module of Mollie. This was clearly wrong. I moved happily to Thirtybees but am getting prolems with important payment modules. I know that there is now finally after a two years a new TB PayPal module. Lesley posted so and maybe hopefully it works. I did not check. I went to Mollie since PayPal did not work before. I canceled all my old PSP's in favour for Mollie. CreditCard, Sofort and "Pay Later". All this is conncected to lot's of time and checking and ... and ... and bookmaking. Always ajusting for a new service is a horror for any merchant and I risk my business. So, you get the gist. I am at the moment really angry and all I can do at the moment is to hope that at least the other payment options (credit card and paypal are the most important onces) will continue to work with Mollie. BUT bew aware they said they do NOT support Thirtybees anymore and so they could stop working without warning. At least for me as a European merchant this Mollie service was very good and nearly without alternative. I and you were told that since Thirtybees remains compatible with Prestashhop V1.6 we are fine. This is clearly not the case at the moment. I do not know why and am asking: Is there a way for Thirtybees to "fake Prestashop" so that modules that 100% support Prestashop but not officially Thirtybees or are forced to not do so (M. D. ??) will for certain work with Thirtybees? The Mollie API must have ways now to recognize that it is dealing via Thirtybees store and perhaps LesLey and Traumflug need to add a masquerade function so compatiblity remains 100%. Else I risk my business now or in the near future with TB since I can not rely on the hope that there may be alternatives each time a module or service decides to stop supporting ThirtyBees. Would't it be nice and a nice gesture in form of the compatibilty vowe that Thirtybees in form of Mr. Lesley, Traumflug or Petr or.... forkes now the Dekker/Diederiks Prestashop Mollie GIT and adjust it for Thirtybees? But perhaps this is not possible du to copyright and code property. I do think it is advisable to run any more the old Thirtybees V3.1.0 module since the new one had additions like getting rid of rounding bugs and more and compatibility for TB has stopped anyways. So we need 1. the PS masquerade.

Hello I still got the problem that the V3.3.5 (newest Prestashop Mollie version) is not changing the status for payment option "pay later" automatically. Please tell me, if it is working for you or not.+ CSS override I can not get working sind V3.3.4 I noticed even more problem with pay later. It seems to have stopped working literally. Orders are not registered in Thirtybees any more !!!

Hetzner Europe, my host, answered: They ask me wheather I know which URL over which port I try to reach. Normally Hetzner allows port 80 and 443. Well, as expected, I do not know. That is the reason I asked in this forum. Looking at the file in concern I see at line 185: // Create a connection exception if it was a specific error code. $error = isset($connectionErrors[$easy->errno]) ? new ConnectException($message, $easy->request, null, $ctx) : new RequestException($message, $easy->request, $easy->response, null, $ctx); return \GuzzleHttp\Promise\rejection_for($error); } I think it might be a ThirtyBees issue nevertheless?

Purity do it again please 🙂 It would be great if someone could post the fix here since it is may be TB related.

Oh, ok. Thank you Petr. Than I suppose I will not have to dig into it since I know I would not understand what is going on. Perhaps I am going to inform my host: HETZNER