WPCharitable

@fabrizio83714

Just to follow up on this. We had team members repeat the same steps in Windows and Linux operating systems with the same version of Charitable. While they got the same typo in the error message (which we already confirmed was an issue and will be corrected in the next release) they were yet unable to confirm the same issue. Both Chrome and Firefox were tested (for Linux in particular the versions were Chrome Version 105.0.5195.125 and Firefox 109.0). The attached screenshot is what was entered in testing (just exporting for a single month of January, for example).

So while we cannot duplicate this in any environment currently our team is still looking into this. Another thing to explore might be the language of the admin – can you confirm what your language settings are for WordPress and general settings in Charitable (including currency)? Our next steps might be to see if those differ in anyway or have any impact.

Thank you!

Hello @fabrizio83714,

Just an update here. We might have located something related to your issue. It was discovered that the alert that notifies a user about an “incorrect date format” is missing a leading “0” if you were viewing that alert in Jan. For example: The alert should give an example of a date of “2023/01/01” and instead it currently gives “2023/1/01” which might lead to some confusion. This will be revised in the next version of Charitable which is coming out shortly.

If this is doesn’t sound like the issue you reported, let us know. I’m going to close this ticket since it’s been a few days but please feel free to restart this conversation (keeping in mind this information and the above question I asked in the initial reply).

Thank you!

@georgebaciu thanks for this information!

So this is a relatively rare issue (apparently even among the WP.org forums) so I spoke with our support team about the error you encountered. The reason why it’s rare is because the error is saying a built-in function to PHP doesn’t exist – a function that is critical to debugging situations. On most installs this would not happen but for some reason on your server it is. It’s encountering that first mention of error_log() because we document certain things when you connect to Stripe for troubleshooting purposes. So this is more of a server/PHP issue then a WPCharitable one.

1. That being said, the first thing you can try is disabling WP_DEBUG and any debugging on your website. According to the info you provided see if you can edit wp-config.php and make sure these variables are false: WP_DEBUG and WP_DEBUG_LOG (leave WP_DEBUG_DISPLAY false). If you don’t see these variables in your wp-config.php that means either a plugin (not Charitable) is forcing them on or your host is.
2. If changing that doesn’t work and you have the ability to downgrade your PHP to 7.4, try that. It has worked for some as a temp solution for some.
3. Most importantly, you might need to contact your hosting company about this. As we said, this is a normal built-in delogging PHP function – it’s possible the hosting company could be deliberately disabling error_log(). Since it’s directly related to PHP, they would be the primary ones to troubleshoot since OTHER plugins have the ability and DO use this function so you might this error eventually if not addressed.

While the next version of Charitable is adding a few fixes for PHP 8.x, this is NOT related to those and believe this to be a setting that the hosting company should confirm and/or address.

If you have follow up or any further questions, please let us know.

I’m going to go ahead and close this thread for now. But if you’d like us to assist further, please feel welcome to continue the conversation.

Thanks!

Hi @giadone,

Charitable’s registration form was designed to be a quick form (often in combination with Ambassador’s addon) which is why normally after register a user can be taken to complete their profile information on the Charitable profile page.

However it is possible for a developer to hook into the applicable filters and add additional fields – this is more for adding your own custom fields/meta-data and depending on what you add might not automatically sync with the “WordPress form fields”. Here’s the code snippet, which likely you will need to place and update in your functions.php (or a custom plugin as long as the filters hook after Charitable loads):

https://github.com/Charitable/library/commit/e82d09a37ea07036dc07b0bf4ea98f8e601f9901

If you want the chance of these working with WordPress form fields you probably want to name fields the same as what WordPress names the meta keys in the user table. I couldn’t find a good link to show the default list but this link seems to have a recent list (“first_name”, “last_name”). Charitable saves it’s donor information with meta keys such as “donor_address”, “donor_city”, “donor_postcode”, etc. Note that code snippets on Github isn’t something officially supported but we try to answer questions as best we can.

There are is also customization to the form shortcode itself if that helps:

https://www.wpcharitable.com/documentation/account-shortcodes/

More expansion (via settings and/or non-code snippets) is on the roadmap for the register form and how/when that is released we will be passing that along in our change logs and updates.

Hope this information provides help. 🙂

I’m going to go ahead and close this thread for now. But if you’d like us to assist further, please feel welcome to continue the conversation.

Thanks!

@fabrizio83714 Good to hear about the alert issue you were experiencing. Can you do the following regarding the auto-selected donation option:

1. Make sure your browser cache is completely cleared/dumped.
2. Share with us the public URL and exact item you chose to be auto-selected.

I’ll share this with the team when you provide it and we will try to confirm. Thanks!

@fabrizio83714 thanks for reaching out. Can you confirm for us what version of Charitable you are using? Thanks!