Jump to content

daxit_x

Members
  • Posts

    51
  • Joined

  • Last visited

Profile Information

  • Activity
    Other

Recent Profile Visitors

3,491,711 profile views

daxit_x's Achievements

Rookie

Rookie (2/14)

  • Dedicated Rare
  • Conversation Starter Rare
  • First Post Rare
  • Collaborator Rare
  • Week One Done Rare

Recent Badges

4

Reputation

  1. Hi Ruxandra I tested the latest offical stripe module version 3.0.3 on a pristine prestashop test installation v 8.0.4 without third party. I tried it also on a live prestashop installation upgraded from prestashop 8.0.2 to 8.0.3 and then to 8.0.4 Both installations are on PHP 8.1 The errors I got are the same on both installations. The flow is the following Install the Stripe official module 3.0.3 Connect to stripe, input the private and public test keys Set the module to redirect to stripe page and Enable separate authorization and capture. Add some catch status to automaticall capture the payment at a later time when e.g the order status is changed to payment accepted or processing in progress... Save Clear PS cache, clear browser cache and delete cookies on pc Go to the front office, add some item to cart, checkout and use a test card, you get apparently a finalised transaction, then wit quite some time for the redirect to the website, when you land back you get the error telling that the transaction was not done, in the backoffice there is no order, but on the stripe account the transaction is marked as succesful go to backoffice, enable debug mode, again clear cache/cookies and so on, repeat the test, you get the same results and you do see how PS does not show any debug message, as if it is working while is not. Furthermore after a few days, I got an email from stripe telling that the webhook (https://yourwebsite.com/module/stripe_official/webhook) is not good The automated email text from stripe is the following: The above message from stripe is related to the test website on which there are no third parties modules or themes, just a plain pristine PS 8.0.4 installation with demo products (I got the exact same email message for the live website tough) At the moment I am stuck with stripe module, I do not like to use the integrated payment form from this new stripe module version, the module assumes that the name of the card holder is the same of the user logged in placing the order, this cannot be always the case, also I do not like the graphical presentation of the module. I could let it go witht he integrated payment form if at least the module would let the customers insert the card holder name as they need depending on the case, in fact not necessarily the user logged is the holder of the credit card, e.g. could be an employee having a card from the company, or could be an employee logged in with the account of a colleague and using a won card or a company card, or could be a user logged with an account of the company and for some reason use a own credit card at his own name, could be the account of a person using a partner's card, could be an account in which the person used a short nickname and is using a card in which of course the holder name is the official full one... and so on. Beside that there are also other reasons for which I always prefer that the payment is done on a a redirect page on the stripe domain and not directly on my website. So at the moment I disabled the official stripe module and I am waiting for a solution. Unfortunately I am unable to fix it by myself. I have no idea if it is due to prestashop, tothe module or both, I wont be surprised if prestashop 8x has something worng too in this respect. I wandering in the blue, I got no idea what to look at by now, should I also check something on the server? Prestashop during installation did not show incompatibilities or missing requisites. However, I hope it will soon be fixed. Thank you
  2. Hello Today I tried to clear out if the problem could in an any way be caused by problems caused by prestashop upgrades or third party theme, modules, cofigurations of the shop or whatever else. To clear out this I used a pristine new prestashop 8.0.4 installation on PHP 8.1 and the (same) latest Stripe official module 3.0.2. I got the same exact results, so there must be something worng in the module Stripe official and/or prestashop 8.0.x I too already contacted stripe and so far got no solution, I also contacted prestashop and received a "write to stripe" response. Anyone else got these errors? Please write it here and please contact prestashop and Stripe too. Does anyone has a clue why this happen? Thanks in advance.
  3. No one else noticed errors with the newest Stripe module 3.0.2 on the newest Prestashop 8.0.3?
  4. I am using prestashop 8.0.3 on PHP 8.1 I am testing Official Stripe Module V3.0.2 The module apparenlty gets correctly installed, do connect to stripe, accept test and live public and private keys, everything seems fine in the back office. I settled the module to redirect the client to Stripe checkout page, trying the process apparently all goes fine, the payment is captured, but when Stripe redirects back to the website I get a fully white blank page. I checked stripe dev dashboard and got this kind of errors (all alphanumeric codes in the error strings below that I guess have to not be shown in public are replaced by this fake string ab12ab12ab12ab12): API version 2022-11-15 Origin: Stripe/v1 PhpBindings/9.6.0 StripePrestashop/3.0.2_8.0.3_8.1.17 404 ERR GET /v1/checkout/sessions/pi_ab12ab12ab12ab12 resource_missing No such checkout.session: pi_ab12ab12ab12ab12 { "error": { "code": "resource_missing", "doc_url": "https://stripe.com/docs/error-codes/resource-missing", "message": "No such checkout.session: pi_ab12ab12ab12ab12", "request_log_url": "https://dashboard.stripe.com/test/logs/req_ab12ab12ab12ab12", "type": "invalid_request_error" } } I contacted Stripe to try to understand what is going on, I was told this: In that document linked by Stripe it this is stated: However, I am not able to to understand what has to be done. Does anyone know why the latest version of Stripe on latest version of prestashop on PHP 8.1 do have this behavior? What can be done to fix it? Digging into this issue I also tried to activate debug mode, overall trying several times the checkout process using stripe with different options such as integrated form or redirection to stripe page, with or without authorize and separated capture, the only three kind of error messages I got are these: An unexpected problem has occurred when retrieve the intent. Notice on line 1295 in file public_html/modules/stripe_official/stripe_official.php [8] curl_setopt(): CURLOPT_SSL_VERIFYHOST no longer accepts the value 1, value 2 will be used instead Warning: Trying to access array offset on value of type null in /var/cache/dev/smarty/compile/a5/fd/bd/ab12ab12ab12ab12ab12ab12_2.file.order-confirmation-table.tpl.php on line 218 Line 218 in that file is the following: <?php if ($_smarty_tpl->tpl_vars['subtotal']->value['type'] !== 'tax' && $_smarty_tpl->tpl_vars['subtotal']->value['label'] !== null) {?> I guess the latter message error is shown in debug mode only. The behavior of the module/prstashop is the same with or without debug system on With the occasion I think to have understood that now the prestashop cache is in /var/cache, and no more in /cache, I did nto know this, however raoming ointo the /var/cache folder I noticed that the var/cache/dev(or prod)/smarty folder has a odd permssions set, whiel as far as I know all folders in prestashop should be set to 755, thsi smarty folder is settled to 711, and I could not find infomration on official documentation about thsi particular smarty folder. Should this folder be 771 or as the others should be 755? (Ialso tied to settle it at 755, but behavior kept to be the same) I have no more hints for now Can anyone confirm if Stripe V 3.0.2 on prestashop 8.0.3 on PHP 8.1.17 do have bugs or works fine? Can you please help solve this problem? Thank you
  5. Hello Yes fazilnlend, that procedure you describe is correct, but not complete at present day with PS 1.7 and PS 8x. At least from prestashop 1.7.7.0 and definitely in prestashop 8x that procedure is not complete and will cause severe problems as reported e.g. by Afriluka and as reported now also by myself having very recently done extensive experiments on prestashop 8.0.2 I checked if anything regarding the tables prefix could be for any reason be written also inside an any table, as foreseen apparently nothing is written in the database, so I checked the whole filesystem and saw that the tables' prefix is noted also in a lot of files into the folder var/cache/prod, substituting the old prefix with the new prefix in all the files (over 200 files) seemed to have solved the problem, apparently, I am not sure yet. I did some tests and saw no problems except than in relation to a module if debug mode is active on the front office I get a huge error message, but this could be related to that specific module only, I have no clear idea about that yet, I need to do more experiments and check e.g. if autoupgrade continues to work fine after these changes and so on. in that var/cache/prod folder the files contained are all related to "symfony" framework, I have no idea of what that system does there, however at first glance looked alike that dynamically injects code stuff into the live code used by the website, just a guess, I have no real good idea. Another thing I am guessing is that this symfony system cache is not deleted using the usual procedure by clicking the button in the advanced parameters > performance panel, I have no idea of how to reset the cache of this sysmfony system, I would like to do it as I am guessing that could be another way to to solve troubles arising after changing the tables' prefix. Does anyone have more information about these issues? Thank you in advance
  6. Hello I installed prestashop 8.0.2 and used a custom prefix xyz_ for the database tables that is different form the defualt one which is ps_ Due to problems with updates of some modules and autoupgrade of prestashop now I want to change the prefix to the defualt one ps_ I thus renamed all the tables in the database using phpmyadmin, this is pretty easy Then I edited the file app/config/parameters.php changing the prefix parameter form xyz_ to ps_ I logged to the back office, the dashboard works fine, but when I tried to enter any other configuration panel I got the 500 internal server error, for instance I tried to go into advanced parameters > perfomance to clear the cache and force the recompilation of the templetes and got 500 internal server error so I enabled the debug system, I tried to go into "perfomance" and now it worked fine and I got no error message whatsoever At this point I disabled the debug and tried again and got the 500 internal server error I enabled again the debug, went into performance, cleared the cache, forced the recomplition of the templates, disabled the debug and tried again to open perfomrance and again got the 500 internal server error. So I decided to try all what is possible, I disabled overrides, same results, I disabled non native modules, same results, I edited a theme file in which I saw that the old xyz_ prefix was still stated and changed all the entries witht he defualt ps_ prefix, and got exactly always the same results, every thing seemingly workign right if debug is on and always 500 internal server error if debug is off I also searched in all tables of the database if the old xyz_ prefix was present somewhere and I found it nowhere I checked the var/cache/dev/container....files and seems that each now contain the ps_ prefix and not the old xyz_ prefix.... so at this point I have no idea where else I should look to solve this issue.... Which is the exact procedure to change the prefix of the database tables in prestashop 8? Please , this is an urgent issue, it blocks me from upgrading prestashop and causes a lot of problems Thanks in advance
  7. Hello I am using prestashop 8.0.2 on PHP 8.1 I tried to change a custom table prefix I used during installation in favour of the default prefix ps_ I got exaclty the same error that Afriluka described in the previous post "The Frontoffice is working well. But the backoffice is showing "HTTP ERROR 500". But when I turn the debug mode on, everything seems to work well. " So it seems that in prestashop 8 changing the tables' prefix, editing the /app/config/parameters.php file, clearing cache and recompile template files is not enough, I searched quite much on the forum, on the docs, in more search engines for some extra information and found none. Does anyone know all what has to be done to change the database tables' prefix in prestashop 8? Thank you
  8. Hi, I got a odd thing, surely depending on my server, when I click that button presta insert the server IP address instead of mine, what can cause this?
  9. Hello I stumbled upon an odd error When clicking on the button to get my own IP for the maintenance mode, prestashop retrieve the server IP and not my own IP assigned by my ISP.... I think that this might be caused by something wrong in my host, but what ? What do you think can cause prestashop to get the server IP instead of my own client IP? On my server I do have Apache+Nginx+Varnish Is it maybe because of the Varnish cache accelerator? (did not tamper to have presta to use it btw..) Thank you
  10. Hello This is a a big flaw of prestashop 1.7. Any suggestion or workaround to import complete translations from a prestashop 1.7 installation to another new prestashop 1.7 installation? Thank you.
  11. Hello Thank you for the reply, appreciated. I saw that works fine in the sense that does not causes errors, but also does not much of what was doing in presta 1.6 or 1.5 So far I see that the module in 1.7 does not validate the VAT ID with he VIES service, do not remove the taxes from the cart if the purchase is done with an EU country VAT ID different from the shop owner's country. Does this module accomplish to this tasks in your installation? I am using prestashop 1.7.2.4, clean and fresh just out of the box, those are the results I got. Bye
  12. Hello Yes I tried right that module, and does NOT work, also the file modification suggested in that post do not work on my presta 1.7.2.4 installation, I am going to try it now on a completely fresh one just out the box, but I guess the result will not change, will post the results in short.
  13. Hello The European VAT module for prestashop 1.7 is very important, almost essential, it is just incredible that prestashop team removed it from the default basic modules in prestashop 1.7, too bad, Anyone found a free solution to this problem? I found this post and tried it, but so far at least for me does not work: [SOLVED] Free VATNumber module FIXED for PS 1.7.0.0-1.7.2.4 Would anyone try it out too and post comments, maybe help to give an end to this issue? Thank you
  14. Hello Wifilogo I am negatively Amazed, just as many others, about PS 1.7 missing this very important feature, it was very nice of you to propose this free solution, finally someone did it, thank you for the effort. In your installation, does your mod work exactly as the it was working in prestashop 1.6? In mine, PS 1.7.2.4, it does not. I am not a coder and have no great skills into this matter, by the way I reviewed the changes proposed and seemed not wrong or dangerous to start with, so I tried i out. Unfortunately does not work as expected, at least on the presta 1.7.2.4 I am deploying the mechanism for which the VAT ID field should appear only if the field Company is used does not work, the VAT field is always visible and does not become mandatory only if company field is used. So if one does set it as mandatory in the addresses tab of the BO everyone have to write the VAT ID and that does not help as the form is used by privates as well as companies. Logically if the VAT ID always appears and is set to be mandatory and does verify the VAT ID on the VIES website then is also not possible to have the field as hybrid, e.g. to ask to input the VAT ID or the Fiscal code or Identification number or other code used by privates in different countries, further more in some countries that is not expected and won't be understood by private potential clients. So the old module for presta 1.6 was doing the work just as needed covering the cases of local private, local company, Eu private, EU company, extra EU private and company, the modification of this same module for prestashop 1.7 should do exactly the same thing at least. Hope a fix is possible, it is really a big pity to see this platform mutilated of such basic fundamental features. Thank you Best regards
  15. This is a real incentive for clients to buy modules in the addon shop, I am glad of this renewed very smart policy from prestashop team, it sounds something alike: "leave it crippled and messy, surely we will sell more modules and stuff.... yep.... because it is scientifically proved that people like silly troubles... "
×
×
  • Create New...