Pedalman
-
Posts
422 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Posts posted by Pedalman
-
-
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
-
If you did not know, Datakick has already done more than the basics on this idea and put it into a module (that is in development).
As said, time and therefore money is alway of concern if things are to be developed and maintained. Perhaps TB needs outsourcing 😉 anyway due to my 40 years usenet/Internet experience I can tell you that solving bugs and polishing the 'marketing' form are an endless story. So, we can be honest and expect that freebies are seldom to come. Therefore I repeat may be it is best to start outsourcing. Maybe due to a public write out where the agencies supporting Thirtbees that are gathered on a monthly basis could pick the most wanted projects.
Develop them in their name and sell, support and maintain... - be part of a great future of an ecomerce platform that simply works, is affordable and greatly sympathetic.
-
*ERROR* 2019/01/03 - 00:01:10: cURL error 52: Empty reply from server (see http://curl.haxx.se/libcurl/c/libcurl-errors.html) at line 185 in file vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php
Im agetting this error in the logs daily at roughly the same time. Does it need fixing?
-
Quote
Hallo DreißigKnie 🙂 Also, ich habe es just gelesen und vermute, dass es doch Mollie sein könnte. Es gibt bei Mollie eine Funktion, die Bestellungen storniert so bald sie nicht versendet wurden. Ich habe wahrscheinlich (habe noch keine antowrt hier erhalten noch von Mollie support) ebenfalls ein ähnliches Problem, da Mollie nicht automatisch mit bekommt, wann eine Order versendet wurde. Eigentlich sollte das gehen via Modulkonfiguration, aber vielleicht steckt der Fehler im Detail?
-
So, Waka., you are using the version that was supposed to be adapted to Thirtybees exclusively and not the latest version V3.3x developed for Prestashop only (and all compatible forks)?
(I am also asking, because two weeks ago I reported here that orders made via "paylater" and Mollie do not! change their order status automatically as they should after being delivered. May be there is a connection to the issues of 30knees)
-
is for anyone the change order status to "ship all" via API working?
-
Hi
I also switched to the PS version at the point when the TB version was marked as 'stalled' in development. M. Dekker made public he will not continue the TB version and concentrate on the PS version already started by Snowcat only.
I never got the CSS style override working :( May be I am missing information to use the right path but since I am msessing around with PS/TB for half a deacade now I thought how to use is. Well, it did not work. That is sad since I really would like to fit the style to my shop.
Moreover I do not get the auto change status function working. I tried all settings but it seems not to work. The API is not changing status for "pay later" in Mollies backoffice. I have this problem with another "pay later / pay on invoice" module by Silbersaiten that has also a function to change the order status. In this case after for example 14 days since order. It never worked. May be there is in my Shop or in TB in general something different to PS considering the order status function?
-
Oh oh
I just found out that you can actually add text to the specific invoice in backoffice orders. It is hidden in the tab 'documents' in backoffice orders. Well, that is nice. Thank you for your tipps !
-
No, I am not looking for a sultion where everycustomer can leave information to be added to invoice during checkout or customer account. I am looking for a way where an employee can add information in backoffice/orders that can be added to that special invoice (orderID)...
For example yesterday a University made an order but informed me that it is necessary that a certain number appears on the invoice...
-
Sometimes customers want me to add important data on an invoice. Is there an elegant way to add this? Best would be directly from the backoffice/orders.
There is already the form for notes to be seen only by employees and not the customers. Could this be 'cloned' and and a variable be addes to invoice.tpl? Or any easier way?
Thank you
-
Hello
thank you for taking time on this. I found this https://css-tricks.com/apply-a-filter-to-a-background-image/ on the web. I am going to play with it next year. As said I find it very interesting how they did it and how it could be implemented into a already running web shop. In my case I tried to upload only product images with 255 255 255 white background. Anyway, there will bi still a small number of images with different bg. May be I will get into offering best product images (quality, size, visual attractiveness) finally. There it would be helpfull to integrate imagemagick into the core image controller perhaps :)
-
Hello I stumbled today about an online shop that is getting better after a long time being not so: https://toom.de
Please have a look at any category and notice the background color of product images. All are of a constant gray tone and I wonder how they did it.
I am no techie but tried to get a clue via browser tools and it looks like they are using highly compressed (too much I think since image quality is low) PNG images and add via some php function a gray tone that fits to overall column color. Could this be imagemagick or ....?
I always wnated to have product images on a gray tone background but never followed this path since I had enough troubles to get a proper white background with my own product photography and Ebay/Amazon once only accepted product images on white (pure white 255 255 255 rgb) backgrounds.
Could some one please enlighten me?
-
Well, I am not going to use it. Since Knowband is not willing to refund it I can sell it ;)
-
I am grateful for your honest words and answer. I really do not like to talk bad about modules or agencies. But in this case I already said that I am was in daily email support conversation with Knowband about issues I noticed in the first 15 minutes and they always responded in a way making me feel like an ape. That was no good experience and I will dig it not. 'PresTeamShop one' I forgot about. I had once a look at their OPC module ( a year ago or so) cause I bought their image compression module. I will check them since I know that their support is fine. Thanks
-
I had the impression that Thirtybees users in this forum are happy with Knowband's OPC module. But after trying to get some answers from Knowbands support the last two weeks that could make any sense I am at the point to quit this module. But before I am gonna say good buy to the ca. 100 EUR I invested and hours I spend to css beautify the module and to translate the gravely bad and dangerously wrong translations they offered for Germany, despite the fact they claim the module is 100% translated... I must ask for your experiences with this OPC module.
What is bugging me most is that it is dependend on the standard cart module with Ajax turned on and that it loads payment options in a windows aftercustomer pressed the buy button.
At least for payment options like bankwire, invoice and checque pressing buy button should be the last step in checkout.
But see what knowband is doing if bankwire is installed:
This is a vanillay Thirtybees 1.07 install. This is far from what I understand under the term "OnePageCheckout". Other payment options are at the moment realised via Mollie module and then things get even stranger.
Is this the way OPC is meant to be or can you tell me how to fix it with Thirtybees? The module could be helpfull but as it is it seems to add steps in checkout instead of reducing them.
-
You can also clean all order data inclusive with custsomer data via some modules. I think TBcleaner can do the job. Else have a look at Vekia's free dboptimzer module ad prestaeurope.
-
Well, then you have to know also all about product variants, how to list them in the feed, how to set up GoogleTagManager to know about variants and how mix all this into Analytics so an automated bid agent can use this data for ads retargeting and standard google ads and perhaps bing and of course Goolge Shopping... If I would knew all this I would run a SEO agency and not a one man show on the grounds of an open scouce ecormerce system.
-
Ok, I can happily confirm that Google Flux module by Casper does indeed export all products and moreover is also pretty straight forward to use. My mistake was that I forgot to standard category for test product in test category to this category. Module exports products from their standard category as it makes sense.
I really would appreaciate to have a form for the googletaxonomielang with search function, so we could more easily and error free add/match categories. Also helpful would be if we were allowed to add only the ID from Goolges taxonomie list for categories. Perhaps we are already since if I do so (e.g. I enter 1255 instead of toys > bla > blub) then 1255 is written to the xml. Perhaps Google has the mental capacitie to understand that?
-
Well
I really appreciate the work you invest Capser into the Flux module. I used for years Moussiq Pro but that did never ever really a good job and Silbersaiten support imght have improved from nothing to something but not for Thirtybees. So, in a nutshell, Moussiq Pro doesn't do the job to 100% as promised.
Gflux I can not get to export all products as I like. I set up a 'test category' and added only one product. This has variants. The standard variant is not in stock. However, no matter what I set up (and yes of course I do have some experience in exporting modules), my product isn't exported.
So, I am really interesed to hear from others here you think that all products are exported and all is fine. I really dislike to buy a 100+ EUR Prestashop module only to export a product feed :(
Official Mollie Module
in Modules
Posted · Edited by Pedalman
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: