Forum Replies Created

Viewing 15 replies - 46 through 60 (of 138 total)
  • Harry,

    Just spitballing here, but I wonder if that table should be named harryconnolly_wp_wysija_list instead? From looking at one of my DBs, that’s the only thing that remotely resembles harryconnolly_wp_wysija_is.

    On the other hand, I could be way off…

    John

    Try this; it should be fully responsive too.

    .home-widgets .home-widgets-5 .widget {
    text-align: left;
    }
    
    .home-widgets-5 .enews .widget-title {
    margin-bottom: 0;
    }
    
    .home-widgets-5 .enews {
    margin: 0 auto;
    max-width: 90%;
    width: 400px;
    }
    
    .home-widgets-5 .enews input {
    width: 100%;
    }
    
    .home-widgets-5 .enews input[type="submit"] {
    width: 200px;
    }

    You’re welcome.

    Adding display: block; to the code in my previous post should drop that submit button below the email field. From there you’d need to decide how you want it to line up and look. If it were me, I’d probably reduce the width of the name and email fields…

    I’m running into a similar issue, though the confirmation emails are being sent.

    The widget is in the footer, and when a user submits the sign-up form the page reloads and stays at the top. If the user were to scroll down they would see the MailPoet confirmation notice, but that’s asking a lot for most users, probably.

    MailPoet’s built-in widget handles the confirmation notice nicely with some AJAX, I believe, leaving the page in the same position and displaying the confirmation notice where the user would expect to see it, though eNews is the better widget overall.

    Any chance we can see this same behavior with eNews Extended and MailPoet?

    gsimusic,

    Adding the following to your style.css should bring the sign up button underneath the email field and make it look like it belongs there:

    .enews-widget input[type="submit"] {
    border-radius: 3px;
    margin: 16px 0 0;
    position: relative;
    width: 80%;
    }
    
    .enews-widget input[type="submit"]:hover {
    border-color: #fff;
    }

    Alternatively, modify lines 909 and 922 of your style.css with those rules.

    Forgot about that default form!

    No, this site is a unique set-up where the client wanted to allow users to register who (supposedly) don’t have email addresses, so I did some custom coding that assigns a default email address to anyone who checks that option on the registration form. So there’s only one email address that’s allowed to be used for multiple users. And it’s an email address that doesn’t actually exist.

    But your questions reminded me that I’m also running Theme My Login, and there’s a setting in that plugin to disable the admin notification email for new users. I selected that option, thinking that TML and GF User Registration were BOTH sending the email, and that solved the problem.

    Thanks for the nudge in the right direction!

    Scott,

    I didn’t even think about $user_id being the object that was causing the warning. I figured it was somehow $email since the warning stated that parameter 1 needed to be a string.

    No, only one email gets sent when using the WP Add New User form in the admin. That’s the form you were referring to, correct?

    Okay, I just deactivated AMA and then registered with Gravity Forms User Registration Add-on. Still received two emails, so I’m going to assume that issue has nothing to do with your plugin.

    I think we’re good then!

    v3.0.1 fixed the warning for me. Still getting two New User Registration emails but I can live with that.

    Thanks for the update!

    In my previous comment I wrote:

    When I comment out the line in that function that includes $wpdb->prepare, the warning doesn’t appear.

    I should have added that if I comment that line and add another with the count hard-coded, such as

    $count = 10;

    then the warning is not displayed, but I still receive two emails.

    Additionally, when I deactivate AMA (and register with a unique email address), there is no warning and I only receive one email.

    If I may add my voice to this thread, I’m getting the same first warning, but not the second.

    Warning: mysql_real_escape_string() expects parameter 1
    to be string, object given in /wp-includes/wp-db.php on
    line 1036

    However, I’m seeing this on the front end and not in the admin. I’m using Gravity Forms and their User Registration Add-on. When the registration form is submitted, the warning is displayed but the user is still registered.

    Something to note though, I think AMA’s count_multiple_accounts function is being called twice during this process, once without the user ID, and the second time with the new user ID.

    I came to that conclusion two ways:

    1. I’m receiving two New User Registration emails from WordPress with the same info in each email, for each registration.

    2. I modified the code in that function to echo the $sql variable, and it prints out the SQL string without the ” AND ID != %d”, and then with it, all in one line.

    When I comment out the line in that function that includes $wpdb->prepare, the warning doesn’t appear.

    Don’t know if that will help. I worked on the AMA code for a while last night trying to solve this, but I need to move ahead with some other aspects of this project now.

    And Scott, thanks for the helpful plugin!

    Thread Starter John Sundberg

    (@bhwebworks)

    As a follow-up to this, I just noticed that when an Editor has permission to view the Queue(s), which I think they should if they’re able to send emails, there are messages there with links to the Settings tab, and if the Editor doesn’t have permission to view the Settings tab, those messages should probably not be visible either.

    Specifically:

    On Queues: Active and Queues: Stuck the following message is there:

    You can adjust these settings here: Settings > Sending Account.

    On Queues: Send History the message reads:

    You can adjust these settings here: Settings > Advanced.

    Thread Starter John Sundberg

    (@bhwebworks)

    Thanks Josh!

    Thread Starter John Sundberg

    (@bhwebworks)

    I agree – seems to be working for me too. Thanks Frankie!

    Thread Starter John Sundberg

    (@bhwebworks)

    Still not excluding entries with that revised filter. I’ve tried a number of different variations on it and it’s still not working.

    Thread Starter John Sundberg

    (@bhwebworks)

    @frankie,

    Thanks for working on this and adding that new filter. Now that I’m seeing these records in the error log, I’m still stuck on how to revise the wp_stream_record_array filter to work with Stream 2.x. and exclude entries from the Stream records.

    I’ve looked through 2.x and 1.4.9, and I can see how the code in the plugin has changed, but I’m not sure what I need to do to tweak the filter for the new version.

Viewing 15 replies - 46 through 60 (of 138 total)