Fee
Forum Replies Created
-
Forum: Plugins
In reply to: [Gutenberg Blocks – Ultimate Addons for Gutenberg] UAG crashes admin screenHey Vrunda Kansara,
thanks for your reply.
The error happens in my local development environment (as I wrote in first post). I always check the updates there first. As I wrote, I had to roll back to version 1.14.3, so my live installation still runs with this version. So there’s no install where you could take a look at (because it’s on my local drive). Are there any other advantages for you by using the ticket form instead of here?
So how can we step in there further?Regards, Fee
Forum: Plugins
In reply to: [Gutenberg Blocks – Ultimate Addons for Gutenberg] UAG crashes admin screenHi there, could you take a look into this issue? I tried updating to all updates, e.g. to 1.15.2 today, but I always have to roll back (to 1.14.3) because the issue is still there. With 1.15.2 it crashes not only the admin scree, but the complete website with error:
Fatal error: Uncaught Error: Call to a member function get_contents() on null in /[…]/plugins/ultimate-addons-for-gutenberg/classes/class-uagb-admin-helper.php on line 282
- This reply was modified 7 months, 2 weeks ago by Fee.
Hi there, this will fix it:
change line #82 in wpbe.php from
add_filter( 'contextual_help', array( $this, 'contextual_help' ), 10, 3 );
to
add_action( 'add_help_tab', array( $this, 'contextual_help' ), 10, 3 );I reported this on github:
https://github.com/nlemoine/wp-better-emails/issues/24Hi @wpexpertsio, you’re right. It’s the latest version but I now performed another debugging against the other plugins. It’s been a plugin conflict, I solved it.
it’s everywhere in wp-admin screen (not in frontend), still in WP 5.4, too.
I now checked something on a complete new site: with the atomic blocks plugin installed and activated the warnings disappear. Disabling the plugin again throws the warnings with a dying page. Reloading the page then works again (with atomic blocks plugin enabled).
On the other site, where I tested before, we do not use the plugin at all.
So maybe there is a reference to the plugin inside the theme, that cannot be found if the plugin is disabled.Hi @atomicblocks theme authors, @wpengine @arrayhq @mindctrl,
did you take a look then?
Do you still maintain this theme? I’m wondering about this issue not being solved, other issues in the support forum not answered since months and no theme update since october?
I know it’s hard to maintain a free theme and I really appreciate your work, this theme has been one of the best out there, but please give us an update about your plans.Forum: Plugins
In reply to: [Gutenberg Blocks – Ultimate Addons for Gutenberg] UAG crashes admin screenMy workaround for now in class-uagb-helper.php from line 1363:
$wp_filesystem = UAGB_Helper::get_instance()->get_filesystem(); if(!empty($uag_instance)): foreach ( $combined as $key => $c_block ) { $style .= $wp_filesystem->get_contents( plugin_dir_path( UAGB_FILE ) . 'assets/css/blocks/' . $c_block . '.css' ); } $wp_filesystem->put_contents( $combined_path, $style, FS_CHMOD_FILE ); endif;Forum: Fixing WordPress
In reply to: Request: set wordpress_test_cookie only on login screenHi Joy, thanks for your answer, but I think there’s a kind of misunderstanding. I’ll try to be more precise:
I do not want to set any cookie.
I do not want to change the behaviour of authentication cookies.
I want to be able to let visitors surf on my sites without any cookies for privacy reasons.I’ve now continued some debugging on different sites and found the issue.
The ‘wordpress_test_cookie’ is not set in pluggable.php.
In wp-includes/default-constants.php this cookie is defined as TEST_COOKIE constant. Via this constant the cookie is set in wp-login.php.
WordPress itself sets this cookie only when visiting the login page – exactly what I want. Of course, the cookie is set on other pages, too, if a login form is included in frontend.
Additionally this cookie is set by a security plugin I use, but it seems to be gone with an update of this plugin now.Forum: Plugins
In reply to: [Polylang] PHP Warning@chouby I’m a developer and really don’t like this statement “just set WP_DEBUG to false in production and that’s ok” because that’s no clean way of coding.
In my opinion it’s time skipping support for PHP < 5.6 as most providers already skipped that.
Your milestone 2.7 is 100% complete – when will this version be released? What’s missing?You’re great! It works. Thanks 🙂
Hi kluver,
thanks for your reply.
Unfortunately it is not showing up.
I already wrote to the German Market support and they told me I shall use the hook “woocommerce_email_attachments” and gave me the info about status ‘customer_order_confirmation’.
Then I looked into your code and saw that you use the same hook and walk through the email_ids activated in the document settings. Currently I don’t get the right way to drop in there.… we use the download link on thankyou page described here:
http://docs.wpovernight.com/woocommerce-pdf-invoices-packing-slips/download-link-on-the-thank-you-page/The generated link uses my-account, that of course is not available for customers.
Forum: Plugins
In reply to: [WC Cancel Order] The Cancel Order button not showing@jodhavishalsingh thanks for checking – nice that it’s working for you, but that doesn’t help me at all. I’m using this plugin now, works very well:
https://wordpress.org/plugins/woo-order-cancel-for-customers/Forum: Plugins
In reply to: [WC Cancel Order] The Cancel Order button not showingsame at me: newest WP 4.9.1, newest WooCommerce 3.2.5, tested with TwentySeventeen
absolutely no button.@mbrsolution sorry, but best practice is to keep the number of plugins as low as possible. This cannot be a real solution for WordPress users, who all have their database blown up by YOUR plugin.
It would be so easy for you to just change the code lines for cleaning transients, that are set only by your plugin.
Let me take a look into your code:
You only need to take out the
do_action('aiowps_perform_db_cleanup_tasks');from functionaiowps_daily_cron_event_handler()in /classes/wp-security-cronjob-handler.php line 28, and put it into functionaiowps_hourly_cron_event_handler()after line 19.If there’s a reason for the other database cleanup commands in function
aiowps_scheduled_db_cleanup_handler()to run daily instead of hourly, split up this function in two different functions and call them by two different hooks.btw. the use of call-time pass-by-reference
&$thisis deprecated in newer php versions, in /classes/wp-security-cronjob-handler.php line 6-7:add_action ('aiowps_hourly_cron_event', array(&$this, 'aiowps_hourly_cron_event_handler')); add_action ('aiowps_daily_cron_event', array(&$this, 'aiowps_daily_cron_event_handler'));and in /classes/wp-security-backup.php line 9-10:
add_action('aiowps_perform_scheduled_backup_tasks', array(&$this, 'aiowps_scheduled_backup_handler')); add_action('aiowps_perform_db_cleanup_tasks', array(&$this, 'aiowps_scheduled_db_cleanup_handler'));I guess there are plenty more call-time pass-by-references in your plugin. This should be fixed.