vlad13

Hello there,
Can you implement a change that would allow having php code inside HTML fragments?

All you need to do is replace the following block of code inside the “gcb” function:

if($entry['type']!="php") {
	return apply_filters('gcb_block_output', do_shortcode($content));//make sure we also run the shortcodes in here
}
else
{
	//execute the php code
	ob_start();
	$result = eval(" ".$content);
	$output = ob_get_contents();
	ob_end_clean();
	return apply_filters('gcb_block_output', do_shortcode($output . $result));//run the shortcodes as well
}		}

Replace with:

if($entry['type'] == "php") {
    //execute the php code
    ob_start();
    $result = eval(" ".$content);
    $output = ob_get_contents();
    ob_end_clean();
    return apply_filters('gcb_block_output', do_shortcode($output . $result));//run the shortcodes as well
}
elseif($entry['type'] == "html") {   // alloyphoto: enable PHP code in < ?php ... ? > tags inside blocks
    ob_start();
    eval("?>$content<?php ");
    $output = ob_get_contents();
    ob_end_clean();
    return apply_filters('gcb_block_output', do_shortcode($output));//run the shortcodes as well
}
else
{
    return apply_filters('gcb_block_output', do_shortcode($content));//make sure we also run the shortcodes in here
}

Thank you!

I just spent about 3 hours on researching the issue, turns out there were multiple points of failure, and I am not sure if the ones I found would apply to everyone, but I think these were major ones…

1. A conflict with the NextGEN Gallery.

Turns out NextGEN does not check if a script file exists before trying to include it. They simply suppress the error by using the @ syntax.
However, ai1wm installs its own error handler which logs EVERY error. This causes the log to grow constantly because these silent errors happens on every request server.
As a quick and dirty fix, you should add this to your error_handler to ignore file inclusion errors.

if ($errstr && strpos($errstr, "include_once") !== FALSE) {
    return;
}

The correct approach, however would be hooking the error handler only when routing your plugin’s methods that handle the export process. ai1wm should be as little intrusive as possible when handling “foreign” requests.

2. Hanging at “Done creating an empty archive”

You are doing a wp_remote_get() to route internal steps to the next handler, however you are not checking the result for failures. In my case, I am using an .htaccess rule to allow access to the admin-ajax.php to a very small number of hosts (my home network only), and the server itself wasn’t in the list of allowed hosts. The wp_remote_get was being blocked by Apache, but because you aren’t checking for errors, the export process simply stops here and never moves past step 1. Adding my server’s IP address to the allowed hosts list has fixed the issue.

3. A conflict in the Wassup plugin

When processing the “export” action, I noticed the following error in Apache’s log file:

PHP Fatal error: Call to undefined method Akismet::isSpam() in /home/alloyphoto/public_html/wp-content/plugins/wassup/wassup.php on line 2561

This also caused the action to terminate.

Basen on this thread I simply removed the file “akismet.class.php” in Wassup’s “/lib/” folder.

I didn’t have the time nor the energy to research this any further, so I don’t know why this error happens only when serving the routed request for the internal steps of the export operation, but removing the file has helped – the request finally reached the appropriate handler and I was able to create and download the export file.

I am hoping you would be able to pick things up from here and make appropriate adjustments to your plugin, which we all would be able to enjoy using again ??
Regards,

The log contains these two error messages repeated multiple times (until I disabled the plugin):

[Oct 23 2015 04:28:08] ERROR_HANDLER
Number: 2
Message: include_once(/home/****/public_html/wp-content/plugins/nextgen-gallery/products/photocrati_nextgen/modules/wpcli/package.module.wpcli.php): failed to open stream: No such file or directory
File: /home/****/public_html/wp-content/plugins/nextgen-gallery/pope/lib/class.base_module.php
Line: 66
——————————————–
[Oct 23 2015 04:28:08] ERROR_HANDLER
Number: 2
Message: include_once(): Failed opening ‘/home/****/public_html/wp-content/plugins/nextgen-gallery/products/photocrati_nextgen/modules/wpcli/package.module.wpcli.php’ for inclusion (include_path=’.:/usr/share/pear:/usr/share/php’)
File: /home/****/public_html/wp-content/plugins/nextgen-gallery/pope/lib/class.base_module.php
Line: 66
——————————————–

Looks like there’s is a conflict, but regardless, here are my 2 cents (4 actually):

1. why does your plugin go into an infinite loop? Last time it wrote over 500 MB to the log file before I realized it went berserk.
2. earlier versions of your plugin didn’t have this issue
3. I am not the only one who is having this issue
4. it takes an awfully long to get this fixed. Will this ever get fixed?

Look, I realize the plugin is free and there are no guarantees. But the older version was perfect for my needs, and I hate to see a good thing go bad and stay neglected ??

Installed 4.6, I am still getting a “Done creating an empty archive” error. The log file started filling up with error messages as before.
I am going to deactivate the plugin until this is fixed for real.

Having the same issue.
Also noticed the log file in all-in-one-wp-migration/storage/error.log is filling up with the following messages:

[Sep 20 2015 13:35:32] ERROR_HANDLER
Number: 2
Message: include_once(/home/***/public_html/wp-content/plugins/nextgen-gallery/products/photocrati_nextgen/modules/wpcli/package.module.wpcli.php): failed to open stream: No such file or directory
File: /home//***//public_html/wp-content/plugins/nextgen-gallery/pope/lib/class.base_module.php
Line: 66
——————————————–
[Sep 20 2015 13:35:32] ERROR_HANDLER
Number: 2
Message: include_once(): Failed opening ‘/home//***//public_html/wp-content/plugins/nextgen-gallery/products/photocrati_nextgen/modules/wpcli/package.module.wpcli.php’ for inclusion (include_path=’.:/usr/share/pear:/usr/share/php’)
File: /home//***//public_html/wp-content/plugins/nextgen-gallery/pope/lib/class.base_module.php
Line: 66
——————————————–

Not sure why it is failing. Also don’t see the point of including plugins’ code when I wanted to export only the database.

This happens after completing an image upload.
The XMLRPC response to a ngg.uploadImage method call contains a chunk of HTML:

<div id=”bulk-forms”><p>Die Thumbnails deiner neuen Bilder wurden nicht optimiert.</p>
<form id=”thumb-optimize” method=”post” action=”admin.php?page=ewww-ngg-thumb-bulk”>
<input type=”hidden” id=”ewww_wpnonce” name=”ewww_wpnonce” value=”101f5f6a56″ /><input type=”hidden” name=”_wp_http_referer” value=”/xmlrpc.php” /> <input type=”hidden” name=”ewww_attachments” value=”a:1:{i:0;i:891;}”>
<input type=”submit” class=”button-secondary action” value=….

Can please someone from Photocrati comment on this? The issue remains and to this day no one has acknowledged it. Thanks.

I have achieved the following conclusion – NGG applies excessive UTF8 encoding when it’s not needed (text string are already UTF8-encoded). I was able to fix this by adding an “intelligent” encoding function:

function utf8_encode_safe($str) {
return mb_detect_encoding($str, ‘UTF-8’) == ‘UTF-8’? $str : utf8_encode($str);
}

and replacing all calls for utf8_encode() in meta.php with utf8_encode_safe()

I am hoping the authors can validate and confirm my solution, and also integrate the fix in the product.

Thanks
Vladimir

Same issue here. Looks like a jQuery incompatibility with the new jQuery library packaged with WordPress 3.5

Issue #475 submitted.

Issue #474 submitted.
Thanks!

Done. #454
Thanks!