I have a contact form and it worked well last November. But days after I did an extension update of "JCH optimized" and "sourcerersLab", the contact form isn't working: there is inconsistency, sometimes it sends but sometimes it does not.
I test the extension update first in my test environment site, and no problem occurred. But when I execute the update on the production site, the contact form doesn't send email. It is so difficult to duplicate the error in the test environment, and it didn't get the same error.
I already checked the Global Configuration >> Mail Settings are set correctly, and have tried PHP mail, sendmail and SMTP, and they are all working fine.
After I read this article, that stated, "sometimes JCH Optimize extension' stuff breaks without noticing right away, and the possible issues can be the Contact Forms are not working."
Reference Link : https://joomlaseo.com/seo-extensions/jch-optimize
I tried to disable the minify JS and CSS area in the extension of JCH Optimized, but still it didn't work. Also tried to disable the whole plugin and delete the cache, also didn't help.
Other things I noticed that when I turn it to offline:
the contact form working well. I received the emails on the messages
sent during site offline.
there is success and error message displayed.
But when it is returned online:
- the contact form doesn't work again.
- And there is no error message when I send message in contact form, even success message.
I am not sure if there is error that has not been caught or what?
My Joomla version: 3.6.4
Can anybody help me?
It seems that one of the updates has caused some JavaScript conflicts (maybe updated some libraries, included some additional libraries, etc...).
Do the following: Check the console log in Chrome after visiting the contact us page, and address all the errors there (press Submit on the contact us as this may generate additional errors).
Related
I am in the process of building a shop on wordpress using woocommerce. All is well except that at checkout there is an endless spinning wheel blocking the payment processing.
I have checked the error logs - which show no errors
I have disabled all plug ins - which makes no difference
I have reverted to the default woocommerce shopfront theme - which has the same result.
The console shows no errors.
I have also followed the instructions here https://docs.woocommerce.com/document/endless-loadingspinner-on-the-checkout-page/ which assumes its a memory limit issue. This did not work.
So, after a bit of digging I found some reference here https://mikejolley.com/2015/11/12/debugging-unexpected-token-in-woocommerce-2-4/ and here https://www.maxsangster.com/blog/woocommerce-endless-loading-spinner-on-checkout/
Referring to these two pages I have been able to see that the json response from /?wc-ajax=checkout is just returning HTML which I would imagine is where the issue is.
However I am running an Apache server rather than Nginx as has been mentioned in some threads and articles. Assuming there is a server misconfiguration of the server or something that needs changing what might that be? Bearing in mind that I do not have direct access to this, so will need to be asking someone else to sort it out for me.
And finally if there is something else I can try what might that be?
Thank you to #plushyObject for generating the spark for this one.
The issue turned out that I had a legacy static html holding page in place as the site's homepage rather than having one set up with wordpress. Simply removing the .html page and letting wordpress's homepage take over solves the problem.
The moral of the story create your holding page in wordpress.
Go to Google Developer Tools, then Go to the Network tab. Click the button and make the request and let that bad boy spin out.
You mentioned the response is returning HTML. Click on the request that goes out that appears to be taking forever (/?wc-ajax=checkout) and then click on the Preview tab to display that HTML. I bet it shows an error or a clue, anyway.
In my case the checkout was working fine on Desktop but not on Mobile. After many search on internet I read the solution of #UntitledGraphic.
I had set a redirect in ht-access. The redirect was showing a different home page for mobile. When I removed it, the error gone. I checked back & forth and was sure the ht-access redirect was the problem.
If you have set any redirect in the Htaccess then remove it. This will solve your issue in this case.
I also checked the redirect code on function.php instead of htaccess again the problem appeared. So finally removed the redirection.
In my own case the redirection was the issue. So I had to delete the redirect I created via Cpanel.
I'm at the end of my rope here and I'm here to get some help. I'm going to try and explain it as best as I can.
I have a website running on Joomla 3.7.2 which you can visit here: https://www.meteordesign.nl
For some reason my contact form does not work anymore. Whenever I click 'send' the page reloads but no confirmation or an email being sent.
I have tried the following:
Switched from PHP mail to SMTP and send a test mail (came in fine).
Used several other contact form modules and components and even an HTML one which you can find here https://bootstrapious.com/p/bootstrap-recaptcha
They all don't work. I have tried disabling my .htaccess file to see if that solved it but to no avail.
You can find the contact form here:
https://www.meteordesign.nl/contact
I don't know if this is important but recently my hosting provider switched to https. Could that be causing it?
I hope I explained it well. If not feel free to ask me more questions, I really need your help fixing this!
So I finally figured it out...
The problem was the cache settings on Joomla at Global configuration > System > System Cache. I had it on Progressive and after setting it to Conservative my contact form worked again!
You are likely running into a JavaScript issue. Just tested this and you seem that you have solved it. Please let us know what the issue was so that others can learn from your experience.
I have a Ubuntu Nginx server (using laravel forge to set it up)
I am now getting 403 errors when posting form data including which I was not getting previously.
The form is posted by a javascript button $('#my-form').submit(); if this is relevant.
Other forms are working fine as long as I remove the tags (used for youtube embedding)
Open up developer console and see more details about the POST request in network tab or console itself. 4XX is a group for client errors, not server or runtime, so expect the issue to be in your implementation. Maybe you use some package that is supposed to "automagically" authenticate or check user permissions when accepting this specific request, and so it fails because you are not passing some header or custom field? Hard to tell without more details.
Add relevant code (at very least your form html) if you want more specific tips.
In this case - I also had a wordpress blog installed with a wordfence plugin operating. The wordfence configuration was enforcing security settings which were preventing any website forms from posting and tags
I'm struggling to figure out how to defeat this process on Hotmail.com.
When I send an e-mail using a PHP script (and PHPMailer libraries, using Sendmail), recipient viewing the message from Hotmail.com gets a very bare message. Images are there, but all of the HTML formatting (styles, attributes, hyperlinks) is stripped away. Not even the <td> attributes remain (such as colspan, cellpadding, etc).
However, when I send the exact same message directly from a regular mail client (or webmail interface), all formatting and styling is preserved intact.
My PHP script sends a customised HTML message to a group of recipients, but it does it one by one (customising parts of the message for each recipient).
It appears that Hotmail doesn't seem to trust my server with the messages and is removing attributes and links as a security precaution. However, there is no way for receiving user to override this. Adding the sender to the whitelist does nothing. I have posted this on a Microsoft forum, without much success. I'm hoping someone here might have fought with the same problem and found a solution, or at least work-around.
I tried various things. I put a time delay of a few seconds between sending of two messages, thinking that Hotmail doesn't like mass mailing, and if two or more messages arrive from same sender at the same time, it will activate this blocking. It didn't help. I tried using SMTP script, sending the message through g-mail's SMTP server. Same problem -- stripped-out formatting.
[update]: I have even tried using Microsoft's own SMTP servers for hotmail, using a valid outlook.com user account to send (from that PHPMailer script). When viewed through hotmail.com web interface, the message is still stripped of all formatting and links.
Meanwhile, when these problem messages are viewed through a mail client (iOS, OSX, Windows, Android, MS Outlook), all is perfectly fine. [/update]
Right now, my work-around is pasting a long URL for this one important link that I want users to use, for recipients who have 'hotmail' or 'outlook' or 'live' in their e-mail address.
Any creative thoughts?
[update 2]After a lot of tinkering, I was able to re-format the message so that at least some of the formatting is preserved, so now, I got <table> tags to work. What's weird is, <bgcolor> also works, but <center> doesn't, nor do any css style attributes (neither to <tr>, nor to <td> or <table> itself). Fortunately, I now have <a href> tags working properly, so the links are functional again. I have basically given up on the whole thing and have developed a separate bare-bones template only for hotmail/outlook recipients.
Frustrating![/update 2]
I'm not sure this is still an issue for you but since I didn't find ANY resources around that matter I thought it was useful to post it here.
I had the same problem and I figured it was that my links were dummies (only href="#") and that outlook stripped them (whereas gmail rewrites the href).
Apparently if there isn't a valid href tag, it strips the link, even if it's been used just for cosmetic.
I would advice not to use them for anything else than links (obviously).
Hope it'll help.
I made a project in the codeigniter framework and uploaded it to a host, the hoster said the site was filling the logfiles of the server pretty fast.
So I checked the error log and for every request i get:
error_reporting() has been disabled for security reasons /index.php on line 36
set_error_handler() has been disabled for security reasons /system/core/CodeIgniter.php on line 72
I asked the host if he could turn on these options because codeigniter needs them for its error handling, but they replied with that i will have to edit my code to disable these functions on their server.
I don't want to edit core files of codeigniter, and i don't really get why it is disabled. Do any of you know an easy solution to fix this error, or some arguments to tell the hoster to change this setting for me?
The reason that the error_reporting feature may be disabled by a web host is to prevent faulty PHP programs from outputting crash messages to the end user that could be used by a hacker to work out how to gain access to the server. PHP crash messages contain a number of details that may be useful to hackers, including directory paths and information about the framework software being used.
It is generally considered good practice to disable error reporting for a production site, so that these messages to not get shown to end users. Switch it on for development, and off for production.
This explains why your host has disabled it.
As for how to prevent the "error reporting disabled" messages going into the log: Well, unfortunately, you can't, unless you edit the code to remove the references to error_reporting.
The CodeIgniter manual contains this page: http://ellislab.com/codeigniter/user-guide/general/errors.html
On this page, it states that the error_reporting code is in index.php, and they encourage you to edit it to stop it reporting errors once your code is in production.
In other words, CodeIgniter says: "please do change this". So don't worry about not wanting to change the core files (index.php isn't really a core file anyway).