Michael
Forum Replies Created
-
Forum: Plugins
In reply to: [Advanced Post List] Invitation to grade plug-in won’t disappearHi guys — I just upgraded to 0.4.3, and it’s still broken. The message block “Looks like you’ve been using Advanced Post…” keeps coming up.
Help?
Michael- This reply was modified 8 years, 4 months ago by Michael.
Done and done.
Thank you!
MichaelHi Liuta — thank you, this fixed the problem. I am able to upload backups to AWS S3 now.
Is there a place where I can donate to your efforts? This is a great plugin and saves me a lot of headaches.
Cheers.
MichaelHi Liuta, thanks for the quick response.
OK, for #2 (downloading a backup), I can see that I’m running into the PHP memory limitation as I’ve configured it. I’ve set it to 512M and the backup is about 850 MB. No problem, I can live with that. I don’t normally want to download my backups, it was something I was trying to do as an interim solution.
For #1, here’s what the debugger log says:
[2017-03-06 08:18:23] xcloner_remote_storage.INFO: Creating the AWS remote storage connection [""] [] [2017-03-06 08:18:23] xcloner_remote_storage.INFO: Doing AWS remote storage cleanup for 30 days limit [] [] [2017-03-06 08:18:23] xcloner_remote_storage.INFO: Transferring backup backup_www.****.com-2017-03-05_11-21-sql-02bbb.tar to remote storage AWS [""] [] [2017-03-06 08:18:23] php_system.INFO: E_ERROR: array ( 'type' => 1, 'message' => 'Class \'Aws\\Multipart\\AbstractUploader\' not found', 'file' => '/home/dalluv5/public_html/wp-content/plugins/xcloner-backup-and-restore/vendor/aws/aws-sdk-php/src/S3/MultipartUploader.php', 'line' => 15, ) [] []Not quite sure what that’s telling me. Any thoughts?
Cheers.
MichaelForum: Plugins
In reply to: [Advanced Post List] [final_end]Hi — this also fixed it for me, thank you!
MichaelForum: Plugins
In reply to: [Advanced Post List] Issues when upgrading to PHP7I have the same issue, on a page where I use APL it’s throwing a PHP Error (Notice) of:
Undefined index: post__not_in wp-content/plugins/advanced-post-list/includes/class/APLQuery.php:437 Call Stack: APLQuery->set_query_base_val() wp-content/plugins/advanced-post-list/includes/class/APLQuery.php:299 APLQuery->set_query() wp-content/plugins/advanced-post-list/includes/class/APLQuery.php:87 APLQuery->__construct() wp-content/plugins/advanced-post-list/includes/class/APLCore.php:2028 APLCore->APL_run() wp-content/plugins/advanced-post-list/includes/class/APLCore.php:1941 APLCore->APL_display() wp-content/plugins/advanced-post-list/includes/class/APLCore.php:1897 APLCore->APL_handler_shortcode() Unknown location do_shortcode_tag() Unknown location preg_replace_callback() wp-includes/shortcodes.php:223 do_shortcode() Unknown location apply_filters('the_content') wp-includes/post-template.php:240 the_content() wp-content/themes/whitelight/template-fullwidth.php:37I’m using APL 0.3.2, WP 4.7.2.
Thanks for all the great work on this excellent plugin.Michael
- This reply was modified 9 years, 3 months ago by Michael. Reason: Added plugin and WP version info
Forum: Plugins
In reply to: [Advanced Post List] [final_end]I’m seeing the same problem. The [final_end] is ignored in the List Content section, it simply gets displayed and whatever follows it is always displayed (even for the last entry in the list).
Something broken there…
I’m running APL v0.3.2, WP 4.7.2
Michael
Okay, doing a manual fix, since PHP 5.6.24 is making an assumption that the undefined constant ‘__XCLONERDIR__’ is exactly that (undefined), I’ve edited xcloner.php and changed line 14 to test for whether the constant is defined. Here’s what changed:
if (!defined('__XCLONERDIR__')) define('__XCLONERDIR__', realpath(dirname(__FILE__))); else (@__XCLONERDIR__ == '__XCLONERDIR__') && define('__XCLONERDIR__', realpath(dirname(__FILE__)));The net effect is the same as before (if it’s undefined, then define it), however this fixes the error notification and Xcloner seems to work just fine (both the UI and the cron script).
Michael
I just updated to the latest release (3.1.5) and this bug still exists. Might be nice to fix it, since it should be easy.
I’m using PHP version 5.6.24, WordPress version 4.5.3
The PHP Error is:
Notice: Use of undefined constant __XCLONERDIR__ – assumed ‘__XCLONERDIR__’
Location: wp-content/plugins/xcloner-backup-and-restore/xcloner.php:14
Calling stack: wp-settings.php:255Michael
Hi, thank you, editing the plugin and adding the missing parenthesis fixed it. I’ll wait for your update to make it permanent.
Cheers.
MichaelHi helened — any progress on getting this debugged & fixed? Still getting oodles of warnings in my log file, and would like to see it resolved or I’ll need to disable the plugin.
Thanks.
MichaelOkay, after looking into this for a bit, I’ve implemented a fix that ensures my fblike links point to the original http: URL which Facebook has been accruing likes for.
In class-front-end.php, I added the following code just after line 132 (with plugin version 2.2.12):
// temporarily fix fblike problems by moving href link back to http: $buffer = str_replace ( "www.facebook.com/plugins/like.php?href=https:", "www.facebook.com/plugins/like.php?href=http:", $buffer );This is clearly just a hack and I wouldn’t recommend it; however, it would be good if a configuration option could be added to the plugin to “not fix fblike links” embedded in a page. This is a problem not unique to my situation, as I’m sure most folks won’t want to have their FB like counts reset just because they moved the site entirely over from http to https.
Michael
I have the same issue with FB Likes. Previously, FB likes for pages came from http://{url} on my site; now the plugin converts all of these references to http
- s
://{url} automatically. Normally that would be cool, but some of my pages have thousands of likes, and they are (in effect) being reset to zero. Not good.
Is there a way to exclude the rewriting for specific lines that include certain references? I know that may sound odd, but for any previously “liked” FB references that were originally http, FB is going to treat the new https: address as different.
For example, this iframe reference using the FB plugin like was coded originally as:
<iframe src="https://www.facebook.com/plugins/like.php?href=http://www.dalluva.com/shop/&layout=button_count&show_faces=false&width=100&action=like&colorscheme=light&font=arial&locale=en_US" frameborder="0" allowTransparency="true" style="border:none; overflow:hidden; width:100px; height:25px;"></iframe>But is now:
<iframe src="https://www.facebook.com/plugins/like.php?href=https://www.dalluva.com/shop/&layout=button_count&show_faces=false&width=100&action=like&colorscheme=light&font=arial&locale=en_US" frameborder="0" allowTransparency="true" style="border:none; overflow:hidden; width:100px; height:25px;"></iframe>Top one shows > 900 likes, bottom one is zero. :-(.
I don’t want to hack the code myself, but this is going to be a big issue for anyone moving their site to this plugin and losing all of the FB like count (which really matters to some customer bases) for their pages that were previously http:. And no, FB isn’t going to fix this (nor do they have any kind of support to ignore the http/https on a link address).
Thanks for any suggestions.
MichaelForum: Plugins
In reply to: [WassUp Real Time Analytics] Database error after updateUPDATE: I followed the recommended path on this post, and it fixed my problem for now.
Michael
Forum: Plugins
In reply to: [WassUp Real Time Analytics] Wassup 1.9 upgrade problemsHi guys — I did the above sequence at the top (disable, re-enable wassup, then reset options, save, disable and re-enable), and it *looks* like it fixed the database writing error AND it is now recording/display traffic properly.
Thanks for the fix!