Jump to content

CJH

Members
  • Posts

    135
  • Joined

  • Last visited

Everything posted by CJH

  1. This error is making Prestashop impossible to use, literally. I have had it come up on occasion, but reloading the page clears it. This has been across more than one version of Prestashop, currently on 1.7.7.3. Now, I am unable to edit any product without it appearing. I have checked file totals and these are well within range, cleared cache, tried turning off cooking control, checked php version (correct 7.3), tried changing the code in TokenInUrls.php (first suggestion did not work, second replicated the invalid csrf token message and saving was impossible), cache disabled (not using any), cannot stop this appearing in a forever loop. If I do display a page and make a change, it immediately states settings saved, but doesn't really do so ... refresh the page and nothing has been saved but the dreaded error appears. Any more ideas? I have a non-functioning website in terms of updating at present. My knowledge of how to code and change things is very limited ...
  2. It took me days in a prior version, so well done on only spending 4h ­čÖé
  3. Thanks for checking - in that case, it's something to do with my own installation.
  4. Yes, it worked for me in 1.7.6.9 and before that. Not for me in 1.7.7.0 (I have not yet updated to 1.7.7.1). If it works for others, then it's just me ... if not, I'll put a ticket on github
  5. Thanks. I don't think I am spending lots of time not growing the business. I'm spending the time I need to make things legal and have done that. I'm not really spending time on this at all now; I still wonder if this is a Prestaship thing or just my system, so I don't spend more time until someone tells me that their installation works while mine does not. I'm not overkilling anything at all ... if the existing native modules do not allow me to stay on the legal side of GDPR, something must be wrong.
  6. There's no errors showing in the log. The max_input_vars is set at 5000 by the service provider - there's a specific warning for this setting that anything higher will be ignored (there are maximum settings for all the php settings) I still don't know if this is a bug and everyone suffers the same thing (changing the tick to cross, but not affecting the actual subscription in the information window), or it's my system throwing a fit somehow.
  7. That looks good, thank you for posting. I can repeat these changes. But I think I am not clear enough. I can turn these on and off, no problem, showing the tick or cross. But when I refer to the customer details, this is a different screen. This one: This is an entry where the customer listing shows a red cross - which can be changed to a tick - but nothing on my system alters the newsletter registration showing in the customer details. And if I generate a list of newsletter registrations (either for my use, or as used by Mailchimp etc), this customer still receives a newsletter. I cannot alter this registration manually from inside BO. In your test, did you check inside the customer account details? This does not show in your video. Again: change a green tick to red cross in the customer list, then check inside the customer information screen and see if it has really changed. Mine does not. Thank you again for taking the trouble to check your system above - these things take time and I appreciate it.
  8. I'll do that ... Can anyone confirm that they can visit the customer list and change the status, and check that it has really changed the status in the customer record? That is, green to red / tick to cross in the list, but visiting the customer page it actually changes the status there? Using the 'unsubscribe' link in a newsletter produces a correct deregistration. But trying manually on my system does not. If anyone else sees the same behaviour I'll raise a ticket, but otherwise I'll look for something wrong on my system.
  9. Thanks for your time, also. It does feel like overkill though, in the sense that changing the status in the customer listing from a tick to across ought to actually change the status in the account in BO (only it doesn't). If there was a checkbox in the BO account for newsletter registration, it would be simple to change it there (it really feels like Prestashop needs to add that facility). Nothing requires a change of email address or password or deleting other information, just changing this status in a simple manner. I'm only changing the password to permit me to reach a point where I can alter the newsletter registration - I shouldn't have to do that and it would be better if I didn't.
  10. Thanks, and I understand the principle ... even if not how to do this. Mysql and working inside the database directly are things I have stayed away from as somewhat beyond my skills. And I couldn't go to a freelance every time I need to change a newsletter registration ... But again, thanks for taking the time to reply
  11. Yes, I understand. But in 1.7.7.0, at least, changing that tick for a cross does NOT change the registration. If I change from a tick to a cross, then check inside the customer account details, the customer is still registered for the newsletter. The registration still shows as green. There is no field inside the account that separately allows me to unsubscribe them.
  12. Thanks for the suggestions. I have deliberately moved away from Mailchimp and started using the paid module produced by Crezzur, though not without difficulties I admit. But, it is working. I have already made sales based on yesterday's newsletter, but have to solve the issue of unsubscribing. The newsletter has an inbuilt 'unsubscribe' and that works ... but where I have to do so myself, which is a requirement under GDPR (that anyone can request that I do this), I have no viable route. I've been put off reporting on github for an instance like this. Essentially, I can observe that I have a red X in the customer list, but green subscribed in the account for the customer, and I cannot alter this. There is no error message to report. I've tried to report similar things before, but told I must fill in the correct format of report. Then when I try, I have an email saying there is not enough detail to replicate this and the report is cancelled. This latest seems the same: I can observe a problem, but no error message, so it seems not worth trying to make a report to github. The only solution I have found for changing the newsletter subscription is to change the password, then use the 'login as customer' module and use the password to allow me to save the change. Of course, the customer must now use a password reset but it is better than me potentially breaking the law by sending a newsletter illegally. I'm surprised that the newsletter registration doesn't have a field to change inside the customer record in BO (other than when looking at the big list). I do thank you immensely for your feedback and suggestions. It's very much appreciated, and thank you for your time.
  13. I have sent a newsletter and some emails from the customer registrations have bounced, including at least one because the customer has died. I must change their newsletter status to remove this, aside from anything else as a requirement under GDPR. I am using Prestashop 1.7.7.0. I can look up the newsletter status in the customer list - it has either a green tick or red cross. I can change these, either way. But, it does not alter the newsletter registration status for that customer - in the customer account, it is still present in whatever the original form it was left by the customer. Example: red cross in list of customers; in the customer full details, still green and registered (and generating a new newsletter list it is still present). Clearing cache does not solve this. I tried the free module for 'log in as customer', which allows me to untick the registration, but not to save the setting (it demands the password, which of course I do not have). I suspect a bug in the software, but how can I solve this to remove the customer newsletter registration - without which I cannot send another newsletter. Any ideas?
  14. Not directly related to this, but I am experiencing problems with newsletter registrations. I've sent out a newsletter, and under GDPR I have to unsubscribe some that are invalid (for example, a request from the widow of someone now dead, to avoid sending another newsletter). Unchecking the newsletter sub in the customer list does not change the subscription status in the account, which still shows subscribed. So I thought to try this log in as customer. In 1.7.7.0 it works - I have the login button, and I can log in as the customer. I can uncheck the subscription to newsletter, but I cannot save this change because it demands a password (which I do not have of course). Is there a way round this? To make a change and save it, without needing a password?
  15. Ha! Uninstall, reinstall and it works ... simple as that, but only with your suggestion. Many thanks Chris
  16. In 1.7.6.9 (and before) the Order Notifications on the Favicon module (2.1.0) worked fine, to put a coloured tag on the browser tab. But on a clean install of 1.7.7.0 (because the upgrade wouldn't do so successfully!), the Notifications doesn't work. At least, not in Firefox or Edge tested when an order comes in (checked on two computers). I really miss this ... Is anyone else experiencing this? I cannot find any reference to it as a bug, so if everyone else has this working perhaps it is a module interfering. The module is part of Prestashop and has the options turned on in Configure. Any clues? I'd like to get it working.
  17. I wonder if there is any solution here ... I have a shop in 1.7.7.0. Products are always priced including postage, which means that combinations are based on the post destination so that the price changes accordingly. But when there is a single product available (say, a used book), it can only be assigned to a single combination and the others show out of stock. Is there any way, or a module perhaps, that will look at the number of products available and show these against all combinations, but not permit more than are available to actually be sold? Example: 1 book exists, with three possible prices/post destinations. It has to be assigned to one, but it needs to show as available to all three to allow other destinations to buy it. But, once sold all three must show no stock. If that made sense, is there any way of achieving this?
  18. This might or might not help someone. I found this thread while looking for a solution to a problem with the contact form (no active send button). I'm working in 1.7.7.0, not yet live but testing the final build. For the send button, I found it was inactive because in the GDPR module I had checked that I wanted a confirmation checkbox to appear on the contact form ... but nothing was there, so nothing was checked and the button was inactive. Turning this off, the contact form worked. But for a long time I was looking for a change to the email. In 1.7.7.0 I have read that the first option, sendmail, has been stopped from working because of a security issue. That means you have to configure SMTP. My account is with Ionos and a shared server. However, Ionos is a web hosting service and users presumably also have an ISP broadband supply to get online. I have Plusnet for this and that handles my email ... so I used the SMTP configuration for Plusnet. I don't think it would matter which ISP is used ... they would all, I assume, come with the ability to set up SMTP. Basically, send your emails through the ISP and not through Ionos to solve this. Hope it helps someone.
  19. And only posting after trying for hours, I straight away find a solution. I looked in contactform.tpl in my theme and found a hook for displaying GDPR consent, and recalled I had turned this on in the native GDPR module. But no checkbox for accepting the policy appeared on the contact form. Once I turned that off in the GDPR compliance module, the button became active and I could sent the message successfully. Looks like a bug - this is the native contact form / or the theme module, plus GDPR module - the checkbox isn't appearing and therefore it is not checked to accept sending, so the button is not active. It is also not down to clearing cache (in BO, browser, or by deleting /var ... none of these helped).
  20. I have a newly developed site in 1.7.7.0 (not an upgrade) and, about to go live and going through testing features, I have found the contact form is not operational and need some help ... Email is set up to use SMTP (the other option returned an error) - the test email works fine, as does any email sent by a customer on registration or placing an order. The problem with the form is that the Send button is not active. When the fields are completed, it does not become active (always a circle with a line through it for 'no'). This does not appear to be theme related (I had another site part built using the classic theme and it doesn't work in that either). I do not have any captur or similar software installed that might block this. Debug does nothing (the button does nothing, so no error is reported). I'm totally out of ideas - need help because I cannot put a site live without a functioning contact page ...
  21. I must report on findings for my BO white page. I think a number of things are likely linked with this. With the suggestion that this was a module-related cause, I went through a period of installing a clean Prestashop 1.7.7.0 and ensuring it was stable by making small changes without a white page. Then adding a module, all of which have proved to be stable and good from good companies, one at a time, then trying things out. I did not then add another module, but wiped it all out and started again with another clean install and a new module, thus trying to determine if two were interfering with each other or not. I found the module, a respected company product (the module was current) and they have worked hard to locate the bug and correct it (if I understand correctly, they found a bug in Symphony and corrected their module to take it into account). I am unwilling to publicly name them (even after literally hundreds of hours given over to this) after the way they responded and tested and worked with me, and that they have released a new module version and are working for the community in this manner. I also suspect this faulty module, which was fine in 1.7.6.9, is the reason why my attempted upgrade to 1.7.7.0 was failing. In short, check modules are up to date if you have a white BO - this could be the reason.
  22. Thanks .. I've tried to change folder names on non-native modules in the current build (which is a restore from an older version), in the assumption that this would take them out of the running, but nothing has changed (still no access, just a white screen when refreshed after clearing /var and browser cache). It seems that even a clean install fails and an upgrade from an existing, running site also fails with multiple errors. It feels like nowhere to go now, with the php in 1.7.6 no longer being supported and my isp requiring a change. The theme I have is supposed to be correct for 1.7.7.0, but in any case this white page has triggered with a clean install and only the classic theme present.
  23. Thanks for the note. PHP is 7.3. The /override folder has folders for classes, controllers and modules. Classes has lots of subfolders. All folders contain an index.php but no other files Trying to log into BO just gets a white page. Literally. No error, nothing, nothing at all to show in a screenshot other than white. However, I noticed that the address has lost the code/key whatever it is called after the admin directory name. I don't know how to find the php memory limit etc; I tried to find out and the suggestion was these are in a php.ini file, but I don't see one to check. It isn't in the root. Turning on debug (with xxxxx inserted for the path): ........................... The autoloader expected class "PrestaShopBundle\Controller\Admin\Sell\index" to be defined in file "xxxxxxxxxxxxxxxxx/vendor/composer/../../src/PrestaShopBundle/Controller/Admin/Sell/index.php". The file was found but the class was not in it, the class name or namespace probably has a typo. in ClassExistenceResource.php line 72 at ClassExistenceResource->isFresh(0)in ContainerBuilder.php line 371 at ContainerBuilder->getReflectionClass('PrestaShopBundle\\Controller\\Admin\\Sell\\index')in RegisterControllerArgumentLocatorsPass.php line 67 at RegisterControllerArgumentLocatorsPass->process(object(ContainerBuilder))in Compiler.php line 140 at Compiler->compile(object(ContainerBuilder))in ContainerBuilder.php line 789 at ContainerBuilder->compile()in Kernel.php line 643 at Kernel->initializeContainer()in Kernel.php line 135 at Kernel->boot()in Kernel.php line 195 at Kernel->handle(object(Request), 1, false)in index.php line 82 ...................................... Which I'm afraid is beyond me to understand what to do with ... I sincerely thank you for your help.
  24. Having failed with updating 1.7.6.9 to 1.7.7.0, I thought to start with a clean slate. I have six times tried to develop a new site in a fresh 1.7.7.0, but every time I have lost back office and only have a white space. No error, just nothing showing. In case this was linked with a theme or module or something, my last try was with a clean install and just moving around, changing some of the settings (like changing preferences to not display brands or whatever; built-in options to change). But then, white page. Front end still works, but I have no way into BO. Is anyone else having this sort of problem? Searches suggest this is something that was solved many versions ago, but I'm getting it with clean installations. Ideas to avoid, cure, fix, resurrect? Six sites and a lot of time now ...
  25. I have discovered that the check boxes for subscribing to the newsletter, and for accepting conditions, in My Account are locked. That is, they will not accept any change (if ticked, they will not untick, and if empty they cannot be checked). This means customers cannot save the form for their account, because the box for gdpr is required. I have a live shop in 1.7.4.4 and another under development in maintenance, 1.7.6.9. Both are identical: locked. The 1.7.4.4 site used to work, and I am sure the new one did also. The only recent change in common has been to update the 1-click upgrade module, but this is disabled in both sites. I do not know the cause ... but especially, not how to fix this. Any ideas how to fix this? Belay that ... something is locking it only on one computer - I tried two more, and there it works. So this is an oddity presumably with the cache ... but very strange
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More