angelalgibson
Forum Replies Created
-
Hi Bel,
Just an update… I originally built my site on PHP 8.0, but there were a lot of issues, so I had to revert to PHP 7.4.
The PHP warnings I listed above no longer occur, so it appears to be related to PHP 8.0.
I do see that Content Control Version 1.1.10 is PHP 8.0+ ready, so not sure what is happening. But perhaps knowing that those errors do not appear on PHP 7.4 may be helpful.
Thank you!~ Angela
Hi there, Bel.
Thank you for getting back to me. Here is the info you requested:
- WordPress version: 6.1.1
- PHP version: 8.0
- Content Control version: Version 1.1.10
- Hosting provider: Kinsta
Let me know if you need anything further from me.
Thank you!
Forum: Plugins
In reply to: [OMGF | GDPR/DSGVO Compliant, Faster Google Fonts. Easy.] Font awesomeThanks, Daan! I’m looking forward to the OMGF plugin update. I have many sites running Elementor Pro with WP Astra Pro. Once I implemented the OMGF plugin to host Google fonts locally on six of those sites, all six Font Awesome icons now just show up as squares. Specifically, Scroll to Top icon on lower right of sites.
The sites have been upgraded to FontAwesome 5. Only change was adding the OMGF plugin to host Google fonts locally.
Thanks for being on top of this!
Hi there Thomas,
Thank you very much for your FAST and detailed reply. I really appreciate it! I ended up doing everything manually for this particular site, but am saving this message thread because I’m going to try the setup again on another site when it’s not as time sensitive and I can play around with everything.
One thing I really like about your plugin is that it saves all the settings when updating themes etc.
Thanks again for your help and for the great plugin!
Just started getting same error yesterday after upgrading.
Warnings:
* Unable to accurately detect IPs
I am running WordPress 4.6.1, and the latest versions of Wordfence (free version) and iThemes Security Pro.
As far as I know all my sites are on the same VPS. The error is only happening for some sites. Not all.
Posting to be included on thread for possible fix. Thank you.
Edit: Just saw message from Plugin Dev that issue should be resolved now. Will advise if further issues. Thank you.
- This reply was modified 9 years, 5 months ago by angelalgibson.
Hi wfalaa,
Sorry for the delay in reply. Thank you for your response.
Yes, I was using the Exploit Scanner plugin.
Thank you for the clarification. I have, unfortunately, experienced several repeated hacks on this website despite Wordfence being installed. My wflogs folder filled up with malicious looking files as well. See here: https://www.dropbox.com/sh/pzx65e7sclxof7z/AAC12UEx54FRNBj__mAMbaW5a?dl=0
So that is one reason for asking my question… basically were hackers able to exploit “base64_decode” and “eval” functions in Wordfence.
And thank you for the tip on Pastebin!
~ Angela
- This reply was modified 9 years, 5 months ago by angelalgibson. Reason: Change the word file for folder
Hi there wfalaa,
Sorry for the delay in reply and thank you for getting back to me. Checking permissions via FTP I can see that permissions on wp-content is also 0755 with Owner and Group set to web server user.
Weirdly over the last few days that read /write error does not seem to be triggering any longer.
I did completely delete the wflogs folder and contents, then set up the firewall settings in Wordfence once again, so maybe that helped?
The only other thing I changed was increasing values in my php.ini file for Max execution and input times. Which should not have anything to do with permissions errors.
Perhaps something resolved on web host end?
Also, to answer your other question, this was on an existing running firewall that had been working previously for some time with no issues.
I will let you know if this error begins to recur.
Thank you,
~ Angela
Forum: Plugins
In reply to: [WPS Hide Login] Still have login attemptsHi TDRock,
You’ll need an FTP client and a text editor.
Once you have logged into your FTP server:
1) Go to /public_html/ if you have WordPress installed in your root folder. Or go to /public_html/wordpressinstall, where wordpressinstall represents whatever you named the subdirectory (folder) where you installed WP.
2) Find the .htaccess file.
3) Duplicate the file using your FTP client in case something goes wrong so you have a backup.
4) Right click and open the .htaccess file with your preferred text editor.
5) Copy and paste this code into the top of your .htaccess file
<Files "xmlrpc.php"> Order Allow,Deny deny from all </Files>6) Save .htaccess file.
If you download the .htaccess file to your HDD before editing, you’ll have to re-upload via FTP to the appropriate place as outlined above.
If you are using Transmit FTP and CODA to make changes, saving right from CODA will automatically save the changes to the server so you won’t have to download/upload the file.
Hope this helps!
Hi, stiliyanstoyanov. Yes it’s not ideal. I still would rather people didn’t have to be sent to a separate thank you page. But at least conversions are being tracked now.
I like your suggestion, but I don’t know how to implement it.
One way to go around this is to create an identical page without the code and use it in case someone fills in the form directly on your website while you use your Thank You page with the AdWords code only when a user comes from your ad.
Making another Thank You page without the AdWords tracking code is simple enough.
But:
1) The AdWords Tracking code is not on the page itself. It’s in a code box provided by the contact form plugin.
2) Even if I had two Thank you pages: one with the AdWords code and one without, I don’t understand how to make sure someone coming to the website directly and filling out the form gets the Thank you page without the code served to them vs how someone coming from an ad gets the other Thank you page served to them.
Also… this particular microsite was built for the sole purpose of being used in an AdWords campaign and has been marked noindex, nofollow. So technically it’s not listed in Google searches. Although the fine print says that is up to Google.
Anyway, in theory people should not be able to find the microsite unless they see a Google Ad. So maybe that will be enough.
I’m curious as to how to implement your suggestion though.
Thanks again for taking time to help.
One of the things that appears to be happening though is that a conversion is being recorded just because the Thank You page gets loaded.
So I still have no definitive way to tell if the conversion is actually from a Google ad or from someone just filling out the form.
Once I changed the form and added the new code and redirect URL, I sent a test message just to make sure the actual form still worked without errors.
Then I did the VPN process.
Just checked and there are two form conversions.
Don’t know what to do about this.
mbrsolution and stiliyanstoyanov,
I was finally able to get my contact form to register AdWords conversions! YAY!
I did have to end up using a redirect to a Thank You page. Not what I really wanted… but at least it’s working.
What I did:
1) Created my Conversion Tracker in AdWords and ticked the choice for “Track conversions on Page load.”
2) Made a Thank You page and marked it noindex, nofollow.
3) Pasted the JavaScript code for the AdWords tracker into the Fast Secure Contact Form Settings > Advanced > Advanced Form Settings > Success page additional HTML: section.
4) Copied and pasted the thank you page URL into the Fast Secure Contact Form Settings under Enable Redirect.
If I hear back from them (have a ticket in with them too) on how to do it just on submit button rather than redirecting to another page, I’ll try to post that here too.
After I did all that, I used a VPN to do a Google search for the terms, clicked on one of the client’s ads and filled out the form. It finally works!
I agree, mbrsolution! =)
Hi, stiliyanstoyanov. Unfortunately I’m not sure how to do this in WordPress
if I was you, I would try to put a tracking snippet directly in my button
If this were an HTML site built with Dreamweaver or similar, this would be no issue.
However, finding the proper body tags in the WP theme files is not working for me.
There are three header.php files. One of which seems to have <body> but no </body>.
And a footer.php file that has </body> but no <body>. So still not sure where to actually paste the AdWords JavaScript code.
Also the Submit button for the contact form is generated through the Contact Form 7 or Fast Secure Contact Form plugin. I don’t have access to the button code itself unless there’s some way to find it in the plugin php files.
I may just have to give in and create a separate thank you page and use this plugin: https://ww.wp.xz.cn/plugins/tracking-code-manager/ so I can move forward on this campaign.
Too many weeks wasted just trying to get things to work properly.
Hi there stiliyanstoyanov,
That was one of the first things I did… The Google Chrome Tag Manager recognizes the code and gives me no errors. Yet none of the conversions ever register in my Google AdWords Admin Dashboard.
I know there should be some because I have used a VPN to do the Google keyword search, click on my own ad (this is actually for a client — so technically a client’s ad) and fill out the form once the landing pages loads.
No conversions counted.
I know the form is sending the info because I get the test emails.