pineapplejuice
Forum Replies Created
-
Forum: Plugins
In reply to: [GiveWP - Donation Plugin and Fundraising Platform] Payment gateways for NGOIt may depend on what country you are located in?
I know for a fact that Stripe supports nonprofits in US and Australia, as my org is using Stripe there.
https://support.stripe.com/questions/fee-discount-for-non-profit-organizations
@talha6248 This may be of use to you, I did something similar. In my case I wanted to show the donation goals and current donation level in local currencies for people visiting our other country sites.
I wrote a small function to query google API and get the exchange rates. One thing to note though is to better do this in a cron once a day or so and save it locally in the DB. Querying API for every conversion slowed down the site drastically, so I don’t recommend that.
Alternatively, if you could do it over javascript, so it runs in the users browser only, then it should be fine to use API. I assume that’s what you want to do anyways, as it sounds you just want to convert some input field.
Anyways, for my use, since I just wanted 2 additional currencies and processing done server side, I just misused the options table to store currencies 😉
You could do something like this:
function tow_cron_activation() { if (! wp_next_scheduled ( 'get_currency_exchange_rate' )) { wp_schedule_event(time(), 'daily', 'get_currency_exchange_rate'); } } register_activation_hook(__FILE__, 'tow_cron_activation'); function tow_cron_deactivation() { wp_clear_scheduled_hook('get_currency_exchange_rate' ); } register_deactivation_hook(__FILE__, 'tow_cron_deactivation'); function tow_exchange_rate() { $prev_rate=get_option('tow_donation_exchange_rate'); $rate=array('timestamp' => time() ); foreach( array("AUD", "INR") as $currCode) { $get = file_get_contents("https://finance.google.com/finance/converter?a=1&from=USD&to=".urlencode($currCode)); $get = explode("<span class=bld>",$get); $get = explode("</span>",$get[1]); $new_rate = preg_replace("/[^0-9\.]/", null, $get[0]); if (! $new_rate > 0) { $new_rate = $prev_rate['INR']; } $rate[$currCode]=$new_rate; } update_option('tow_donation_exchange_rate', $rate); } add_action('get_currency_exchange_rate', 'tow_exchange_rate');Then you just would need to do something like get_option(‘tow_donation_exchange_rate’); to get the rates.
It’s a quick hack, but does the job.
Here it is: screenshot
@dlocc I did some more digging, I think this may not be multisite related, but happened after upgrade to Give 2.0.
I just coincidently noticed this since I’m converting to multisite for which I used my production setup and DB as base. (Otherwise your steps are correct)
Checking on my production system, which is still single install, I see that it has the same problem. Looking at the dates of the last correct image upload, it is just the day before I updated to give 2.0.
Hence I suspect it must have been the update to give 2.0. On my production I’m now running give 2.0.2, which still has this issue. On my stage I’m running give 2.0.4 which also exhibits this behavior.
I’m not sure how to solve this now…
I’m having the same issue. I switched to multisite and just noticed this as well.
If I upload media through the Media->Library->Add new, they are uploaded into the wrong year/month directory. Specifically they are uploaded into the directory with the year/month of when my donation forms were created.
If I disable all give plugins, the issue goes away.
If I change the publish date of all donation forms on a site, then uploads in that site go into the year/month of the new publish date.
:thumbsup: I tested it and it works. Thanks for the quick turnaround. Now I don’t need my workaround anymore.
- This reply was modified 8 years, 3 months ago by pineapplejuice.
I found where the problem is. It looks like that when you do switch_to_blog(), the ‘donors’,’donormeta’,’customermeta’,’paymentmeta’,’logmeta’, ‘formmeta’ tables aren’t switched in the plugin.
I worked around the issue by doing this right after the switch_to_blog call:
foreach(array('donors','donormeta','customermeta','paymentmeta','logmeta', 'formmeta') as $name) { $newval = preg_replace_callback('/^(wp_)(?:\d+_)?(give)/', function ($match){global $blog_id; return $match[1].$blog_id."_".$match[2];}, $wpdb->$name); $wpdb->__set($name, $newval); }That fixed the problem for me.
Right before restore_current_blog(), I reset those to the original ones.
Not sure if it’s something you guys can or want to address in your code, but this workaround seems to do the trick for me.
I added
$_SERVER['HTTPS'] = 'on';to wp-config.php. Afterwards I went to wp-admin and all the styles were still broken, but now I had a button to activate SSL in settings->SSL. After clicking that it seems to work,Since I want to force https for all sites anyways, I’ll just leave the override like that in place.
I definitely didn’t have these problems in the single site setup. Oh well, seems to work now.
For anyone interested, this issue is resolved in the latest UM2.0 build.
Well, it works, sort of. In general it works fine using the hooks, but I’m back to the original problem that CSS in the HEAD won’t work.
It looks like um_convert_tags() which is used to return the email content in prepare_template() strips various content within curly brackets {}. I assume the thought was that only meta keys would be in curly brackets?
This will break CSS if it’s in the HEAD like so:
<head> <style media="all" type="text/css"> @media only screen and (max-width: 620px) { .span-2, .span-3 { max-width: none !important; width: 100% !important; } .span-2 > table, .span-3 > table { max-width: 100% !important; width: 100% !important; } }That would then look like this:
<head> <style media="all" type="text/css"> @media only screen and (max-width: 620px) .span-2 > table, .span-3 > table }Any suggestions how I can get custom CSS working in HTML emails in UM2.0?
Thanks
Looking through the code, I assume I’ll need to add_action for um_before_email_template_body to output the <head> and add_filter for um_email_template_body_attrs to change the body tag itself. Then I could override the template files that are used for the body by just dropping them into the theme.
Well, I guess I can do that. Good thing you guys added hooks!
Thanks
I had the same issue. UM 2.0 wasn’t transferring the settings from UM 1.x over correctly. They fixed it last week in the latest version. I had to revert back to my DB backup of before upgrade to UM2.0 and then install the latest UM2.0 version you can get here: https://github.com/ultimatemember/ultimatemember/tree/release/2.0
Basically the whole content restriction stuff wasn’t working if you were upgrading from UM 1.x- This reply was modified 8 years, 6 months ago by pineapplejuice.
Cool. That explains it.
Disabling registration in WP settings is a nicer solution anyways.Thanks
Forum: Plugins
In reply to: [Child Theme Configurator] widgets not copied to child themeAppreciate the fast response and offer to help. I figured it out.
I just recreated empty widget areas in the child theme using the exact same name as used in the parent theme. (Under Appearance->Widgets in “Manage Sidebars” add new sidebar)
Then in Child Theme Configurator rerun the “Copy Menus, Widgets and other Customizer Settings from the Parent Theme to the Child Theme” option.
That caused all widget elements and their content to also appear in the child theme.
This plugin is definitely a time saver especially for people new to child themes!
Thanks
Actually, looking at um_rewrite.php I figured out that my problem was, that in Ultimate member -> Settings -> Setup, I had set “User page” and “Account page” to the same page. That messed up the rewrite rule.