AveryCohen

Forum Replies Created

Viewing 14 replies - 1 through 14 (of 14 total)
  • Thread Starter AveryCohen

    (@averycohen)

    I put the site in debug mode and it’s not throwing any errors.

    Thread Starter AveryCohen

    (@averycohen)

    The original developer modified the theme. I installed a fresh Sydney and Child theme on our dev subdomain, so it is clean.

    Same. Not all plugin developers are adhering to the recent Elementor update.

    Deactivating plugins one-at-a-time, I found:
    1. When I deactivate reCaptcha Pro, it eliminates two of the errors. Not a good sign, as reCaptcha Pro captures a lot of spam for our site.
    2. Another plugin that was causing errors is an outdated plugin called “Custom Facebook Feed Pro Personal.” (We were already planning to replace this, so now it’s happening.)

    Also note that the error does not occur when I am logged in as administrator and have the admin bar at the top of the page.

    • This reply was modified 1 year, 10 months ago by AveryCohen.
    • This reply was modified 1 year, 10 months ago by AveryCohen.
    • This reply was modified 1 year, 10 months ago by AveryCohen. Reason: Edited to reflect recent findings
    Thread Starter AveryCohen

    (@averycohen)

    That was quick! Thanks!
    I have installed the update.
    Still trying to track down the cause of crashes. While the logs showed the crash subsequent to the Unique Headers error, it was an hour or more later.
    Still, happy this is cleaned up. Thank you.

    Thread Starter AveryCohen

    (@averycohen)

    Thanks, Barry.
    As I said, we love the functionality, and the layout gets the job done (which is what you were going for). We are using a purchased them (Church & Event from Vamtam), which we tweaked to be even more event-centric, thanks to the functionality provided by Events Calendar Pro, so it’s not bad.

    At some point, I would like to revisit usability and design of the event detail page and the /events/ page layouts. Our members are (slowly) moving towards RSVP and ticket purchases, which makes the staff happy!

    Here’s the update on this:
    You can easily track successful Contact Form 7 submits in Google Analytics using Google Tag Manager. This uses wpcf7mailsent, required 2017

    Contact Form 7 sends a custom JavaScript event (wpcf7mailsent) on successful form submission, and the form is identified in the Click URL variable, which, for forms, contains the form action property.

    Create two tags and one trigger:

    Tag 1 name: Contact Form 7 – Success Listener
    Tag type: Custom HTML
    HTML:

    <script type=”javascript”>
    var wpcf7Elm = document.querySelector(‘.wpcf7’);
    wpcf7Elm.addEventListener( ‘wpcf7mailsent’, function(event) {
    dataLayer.push({‘event’ : ‘CF7formSubmitted’});
    }, false );
    </script>

    Triggering: All Pages (Page View)

    Tag 2 name: Contact Form 7 – Success Submitted
    Tag type: Universal Analytics
    Track type: Event
    Event Category: Form Submitted
    Event Action: {{Click URL}}
    Event Label: optional
    Event Value: optional
    Triggering: CF7 Form Submitted – cf7mailsent

    Trigger name: CF7 Form Submitted – cf7mailsent
    Trigger type: Custom Event
    Event name: CF7formSubmitted
    Trigger fires on: EVENT matches CF7formSubmitted

    Note case sensitivity.

    People with more free time can create more advanced reporting by adding the following:

    1. Variable (macro) with type JavaScript to extract Form code from {{Click URL}},
      especially valuable if you have the same form appearing on multiple pages
    2. Variable (macro) with type Lookup Table to translate form code into form name.

    Same.

    OK, once I laid it out like that for you, I was able to test the syntax and can edit our multi-edit blocks!

    Thanks for the vote of confidence, Dries

    Thanks, Dries, AJ’s out this week, but I see something very different.

    In the Main Index Template (index.php) and page.php, we see the following code:

    <?php
    /*
    MultiEdit: Right
    */
    ?>
    <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “https://www.w3.org/TR/html4/strict.dtd”&gt;
    <html>
    <head>
    <link href=”<?php bloginfo(‘template_directory’); ?>/favicon.ico” rel=”shortcut icon” type=”image/ico” />

    For “internal page template” is similar code:

    <?php
/*
Template Name: Internal
MultiEdit: Right
*/
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "https://www.w3.org/TR/html4/strict.dtd">
<html>
	<head>

    This sounds more like spam than a hack to your website. We see this kind of spam more often in referring websites listings than in content listings. “Oh, look, semalt.com is sending us so much traffic…”

    You can eliminate these spam entries from showing up by creating filters in Google Analytics admin to block these entries. You can block the spam pages showing up in your usage reports by creating a filter based on hostname.

    Thread Starter AveryCohen

    (@averycohen)

    Thanks, Tara, but I thought I was clear that setting the permissions back to 755 results in the upload capabilities no longer working.

    Files uploaded (when permissions were 777), and folders created by WordPress functions show as having no owner. And “no owner” can’t add files to folders with 755 permissions.

    The WordPress functions should inherit some authority, but no longer do now that we are running under 4.1.1.

    There is something different in 4.4.1, and it isn’t working for us. It’s rendering many features unable to perform their duties. Not only can’t we upload media files, but our backup plugin can’t create files.

    I am also unable to load media files subsequent to upgrading to WordPress 4.1.1. Getting the error: “file.png” has failed to upload due to an error
    Unable to create directory wp-content/uploads. Is its parent directory writable by the server?” — yes, it is 775.

    Per a “resolved” posting, I also get the message “XML-RPC server accepts POST requests only.” when I open https://www.put-your-domain-name.here/xmlrpc.php&#8221;

    I would also note that I was able to load media prior to upgrading to 4.1, and that I was NOT able to automatically upgrade to 4.1 — I had to FTP the zip file and upgrade manually.

    My ISP claims that this is NOT their doing.

    I have the same problem with a fresh plain vanilla version of WordPress 4.1.1 (with no plugins installed) that I loaded on our server.

    Next steps?

    I am also unable to load media files subsequent to upgrading to WordPress 4.1.1. “file.png” has failed to upload due to an error
    Unable to create directory wp-content/uploads. Is its parent directory writable by the server?” — yes, it is 775.

    I also get the message “XML-RPC server accepts POST requests only.” when I open https://www.put-your-domain-name.here/xmlrpc.php&#8221;

    I can not add media from the left side menu. I can only add media via FTP, and then have no access to the media library.

    I would also note that I was able to load media prior to upgrading to 4.1, and that I was NOT able to automatically upgrade to 4.1 — I had to FTP the zip file and upgrade manually.

    My ISP claims that this is NOT their doing.

    I have the same problem with a plain vanilla version of WordPress 4.1 (with no plugins installed) that I loaded on our server.

    Next steps?

    Thread Starter AveryCohen

    (@averycohen)

    Any plans to add? Crawling the site is a frequent QA task for us.

Viewing 14 replies - 1 through 14 (of 14 total)