Thomas S

Thank you for the update!

I’ve been trying to figure out if I could work around your specific case, but couldn’t think of a way without rewriting portions of how WordPress handles the paths to the uploads directory, so that wasn’t really an option. ??

Hi,

Not if you want to import the member information. We need a “peg” to link the membership/user combination to…

Hi again,

So the plugin uses the result of the wp_upload_dir() function call for the path to the import .csv file.

If HostGator has decided to modify the return of that, but not update the path in the call, I don’t know what more I can do.

It’s a standard WordPress function, and HostGator apparently has decided to override how they handle the path to it in the underlying file system (without seemingly making sure nothing breaks in the WordPress platform).

Since wp_upload_dir() also has a filter, I would have expected them (HostGator) to have taken the time to make sure any calls to wp_upload_dir() returns the (different) path they actually upload to…

We’re kind of stuck here.

It seems to me like HostGator has made half-tested changes to how they expect WordPress to function, but they’re not providing any documentation on how to actually deal with it in a way that allows a plugin to work on _any_ platform.

I’m personally not a fan of HostGator for (amongst other) this reason, but I’m genuinely willing to try and figure out how you can make my plugin work with their apparent non-standard behavior.

• This reply was modified 6 years, 11 months ago by Thomas S.

Hi Liat,

Apologies for the delayed response, but have been offline for a few days.

I understand what you wrote, so thank you for investigating.

I just arrived at my destination after 24hours of air travel, so will need to revisit this tomorrow.

• This reply was modified 6 years, 11 months ago by Thomas S.

I feel horrible for “punting” on this!

Please let me know if they have any suggestions for how a plugin that relies on the wp_upload_dir() data being correct is supposed to know that they’re modifying the paths under them (if they have a workaround, I’m happy to try and implement it).

Hi,

If by renewal you mean recurring payment(?), those follow whatever the subscription plan on the payment gateway follows. It _could_ follow the startdate value, but that’s not guaranteed. Whether day of the month in the startdate aligns with the day of the month for the recurring billing date depends on other add-ons, custom code on the system, how the payment gateway handles the end of the month, etc.

Just to be clear; For recurring billing, your WordPress/PMPro host does _not_ trigger or manage payments. Payments are managed on the Payment gateway (PayPal/Stripe.com/Authorize.net/Braintree/2checkout, etc’s servers).

You cannot import a user/member to Paid Memberships Pr and expect that import operation to result in payments.

This is because PMPro doesn’t allow an import to create a subscription plan and submit the payment method data for that subscription plan.

Your users have to provide that information individually. If you want them to create new subscription plans, you have to import them with a membership that has an enddate and use the available tools to remind them to renew/update/etc.

PMPro has a few posts on their forum that covers ideas on how to increase the possibility that an imported user will update their payment info and resume a recurring billing membership on your site.

Huh.. Seems like they’re _way_ overthinking this and causing themselves unnecessary support tickets, but that’s their prerogative I guess. ??

I don’t have an easy fix for you in this case, sorry. My concern is that allowing ‘random’ file paths would be a major security issue IMHO. Off hand, I can’t come up with a non-complex way (short of all sorts of whitelist/blacklist logic being added) to prevent someone from specifying the wp-config.php file path and thus potentially get access to salts, DB passwords, etc…

Hi,

Assuming you already have a subscription plan on the payment gateway you’re using for that member, you do not use a membership_enddate value for the members who are to continue their recurring memberships.

You cannot use either of the PMPro import plugin options to _create_ a recurring billing plan for the members being imported. They have to have one established already.

The cycle number is the numeric frequency for when you’d anticipate the payment to be billed, and the cycle period is the time value. Thus, for a monthly recurring billing membership – _with_ a pre-existing payment gateway subscription/automated recurring billing plan in place, you’d set the membership_cycle_number to 1 and the membership_cycle_period to ‘Month’.

Hi,

The 1st argument in the PMProRH_Field() object definition for the custom field is used as the metadata key (name) of the field when stored by Register Helper in the database.

This is why that argument cannot begin with a number, contain whitespace and should avoid dash - characters in the name (underscores and lowercase letters are OK).

For this import tool, that name, as entered in the source file for the field definition, is the column name to use.

• This reply was modified 6 years, 11 months ago by Thomas S.

So… Those are obviously not the same directory (which explains the error message).

You may want to reach out to your hosting provider for an explanation as to why the directory returned by the wp_upload_dir() function (specifically the based key in the array returned by wp_upload_dir()) and the file system do not seem to map correctly…

Hi,

Can you verify whether the file testexport15.csv is present in the directory indicated: /home/content/a2pewpnaspod05_data06/08/41540008/html/wp-content/uploads/e20r_imports/ ?

Hi,

It seems like you’re somewhat uncomfortable with the process and with researching the examples that exist for the import file, plus the documentation that is available both on this page and for the underlying technologies used by your website.

It may be worth your time/money to hire somebody/a developer to help you with the import.

Updated beta (2): https://dl.orangedox.com/a8aj7MJINYrH9IPVHx

Can we use the ID numbers instead

That’s the only thing you _can_ use (it’s why the name of the column is membership_id).

The MySQL database site has great documentation describing what the allowed MySQL DateTime format is.

Hi Liat,

I have a new beta version I’m hoping to make available later today, or first thing tomorrow. I found a bug and believe that when I squashed it, I also fixed the issue you’re reporting with background imports.

Thank you for your patience (and for the donation!)