Forum Replies Created

Viewing 15 replies - 1 through 15 (of 15 total)
  • I have the same issue. It was working fine until a day or two ago, now all times are off 6 hours and changing timezones/offsets has no effect. Unfortunately, I think this plugin is not supported anymore. If you find a solution, please post here. I will also be looking for a solution.

    Here are my plugins:

    Duplicator Version 1.3.16
    Easy Table Version 1.8
    Huge IT Lightbox Version 2.1.0
    Image Widget Version 4.4.7
    Nav Menu Roles Version 1.9.3
    PayPal Donations Version 1.9.5
    Per page head Version 1.4.2
    Postman SMTP Version 1.7.2
    Print, PDF & Email by PrintFriendly Version 3.14.6
    Really Simple SSL Version 3.2.3
    WP Google Maps Version 7.11.35

    Quite a snide and unprofessional reply, but to answer the question for you, there are many ways developers can make such a transition.

    For example, grandfather in past loyal customers in some way. Perhaps when you’re transitioning to the new format give a warning and two months for current consumers to pay a one time fee.

    I tried these. The issue for me is that once we leave the website, I don’t have a way to get the user id to then save the postmeta data to the usermeta (the session expires).

    I suppose this is of my own making since I intercept the woocommerce process to assign my own roles based on what customers buy, thus all my customer numbers in the postmeta for an order are not set (so I can’t $order->get_user()).

    I’ll still be looking to see if there is a place to hook in after the checkout form is submitted, but before the redirection to the paypal site.

    Thanks for all your help Caleb!

    Thanks for the reply!

    I was just working on that solution (putting it in a custom thank you page). The problem I ran into was people who paid via paypal and then never returned to the store and thus did not trigger the thank you page.

    I can’t use an auto return because I use the paypal account for several different store fronts that return to different places.

    There must be somewhere the form data from checkout is written before we leave for the paypal site.

    The file is in wp-includes and is called just logcurl. I guess that partially solves the mystery since it shouldn’t be there!

    I’ll consider this a rogue file and investigate further.

    I’m using whynopadlock to check for site insecurities and I get:

    Insecure URL: http://none/

    To be fair, I’m only assuming it’s from wp-includes/logcurl because when I grep my entire directory for “//none”, it is the only file that contains the string.

    That’s fantastic! Thanks so much.

    Just adding this for future readers…

    Thanks for setting me on the right path. It is mostly a matter of styling being stripped out. Unfortunately, I don’t have the authority to change how they do the Constant Contact emails and the people who do don’t want to do the custom editing required to put style information inline.

    However, the main problem for me was due to this line in the html:

    <td class="HideInMobile" colspan="1" rowspan="1"><img src="" alt="" height="5" hspace="0" vspace="0" width="1" border="0"></td>

    It inserts a huge gray box into the table that destroys everything.

    So just add in your own style sheet:

    .HideInMobile { display: none; }

    and everything is at least visible, just ugly because of many nested tables. Next I need to find where in Postie to catch these emails and strip away all these outer tables…

    Hi, I did send a test newsletter title: test newsletter from jjk697

    Unfortunately, I couldn’t duplicate your error. Make sure you’re using the newest WordPress version and newest plugin version. Fill out all the appropriate new event fields before you save it.

    If that doesn’t work, maybe the developer can help. Sorry I can’t be of more assistance.

    Can you clarify? What do you mean by “adding new i”?


    This is a bug. It’s because in the admin manual payment file, a php array is treated as an object. To fix it, go into the file:

    payments/evr_admin_payments-post.php (around line 80… not exactly sure as I’ve heavily modified my files) and change this block of code:

    $ReplaceValues = array($payment_dtl->payer_id, $payment_dtl->first_name,$payment_dtl->last_name,$payment_dtl->payer_email,stripslashes($event_dtl->event_name), $company_options['company_email'], $payment_link, $payment_dtl->mc_gross, $payment_dtl->txn_id, $payment_dtl->txn_type,$payment_dtl->address_street, $payment_dtl->address_city, $payment_dtl->address_state,$payment_dtl->address_zip,$payment_dtl->address_country, $event_dtl->start_date, $event_dtl->start_time,$event_dtl->end_date,$event_dtl->end_time);

    to this

    $ReplaceValues = array($payment_dtl['payer_id'], $payment_dtl['first_name'], $payment_dtl['last_name'],$payment_dtl['payer_email'], stripslashes($event_dtl->event_name), $company_options['company_email'], $payment_link, $payment_dtl['mc_gross'], $payment_dtl['txn_id'], $payment_dtl['txn_type'], $payment_dtl['address_street'], $payment_dtl['address_city'], $payment_dtl['address_state'], $payment_dtl['address_zip'], $payment_dtl['address_country'], $event_dtl->start_date, $event_dtl->start_time, $event_dtl->end_date, $event_dtl->end_time);

    Note that the event_dtl elements don’t need to be changed, as they are php objects. While you’re in there also change the line a few above it to:

    $payment_link = evr_permalink($company_options['return_url']). "id=".$payment_dtl['payer_id']."&fname=".$payment_dtl['first_name'];

    to fix the same error. Then also update payments/evr_admin_payments-update.php for the same two bugs.

    There are several places in the code, for example in

    public/evr_public-confirmation.php and

    where the “From” field for the email headers is set to $company_options[‘company’] which is not a field in the database. Rather it should be $company_options[‘company_name’]. It’s minor because it only affects the From field in the emails sent out, but it’s an easy fix.

    This is intentional. I think there’s a little confusion over the use of “Attendee.” The person who signs up will always be primary on the registration. The true “attendees” of the event are listed under that person’s name in the database in the serialized “attendees” field.

    It would be productive to think of the person’s name who signs in with name and address etc. as the Registrant (that’s how I’ve relabeled the order forms, etc. for my page). You could send a confirmation email with the attendees listed, but it would take modifying the code. It is meant to go to the registrant since presumably they paid.

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