primathon

Thank you so much for that speedy response! Much appreciated!

This plugin appears to only support comments for Posts and Products. Attempting to import Page comments will fail with the “This post doesn’t exist” error.

This restriction can be removed by editing the /plugins/comments-import-export-woocommerce/includes/importer/class-hf_cmt_impexpcsv-import.php file on line 658, in the product_id_not_exists() function. Change the SQL query from:

$query = "SELECT ID FROM $wpdb->posts WHERE ID = %d AND post_type='post'";

to:

$query = "SELECT ID FROM $wpdb->posts WHERE ID = %d"; (or change ‘post’ to ‘page’ above if you want to explicitly only search Pages)

After making this change and saving the file, importing comments for Pages now works as expected.

• This reply was modified 4 years, 1 month ago by primathon.
• This reply was modified 4 years, 1 month ago by primathon.

Very true; in this instance I suppose I was expanding the definition of “core files” to include the database tables created by the plugins.

I’ll send you a separate message with some ideas on the master/client feature and share what I’ve experimented with so far. Thanks!

Shea – thanks for responding so quickly! In keeping with the ethos of the Code Snippets plugin, I really try to avoid modifying any core files directly, as there’s no telling when an update may disrupt or break the site.

This feature request is actually more of a prerequisite for building out a master/client “repository” functionality that I’ve been working on, where one “master” site can run the most up-to-date versions of the snippets, and the “client” sites can pull down the most recent version from master. It may not be super useful for a single-site user, but for those of us who use Code Snippets as an extremely important (read: crucial) dev tool in managing many client sites, this would be a huge help in keeping things updated across the board.

I’m actually about 80% done coding this already; is there a good way to contact you directly about how to possibly implement this power-user functionality while still keeping things lightweight for most users? I looked around for an email address but didn’t find anything. Thanks again for your time.

Hey @shanept, I fixed it! And it’s a super ugly fix, too!

Digging through stack traces got really boring after a while, so I just went for the primitive brute-force approach. Thankfully, the offending Divi code does a function_exists check before defining itself, so I’m abusing that. For the fix, insert this block around line 12 in /src/Ajax.php (right after you define WP_ADMIN as false and before requiring admin-ajax.php):

define( 'WP_ADMIN', false );

// Ugly stub hack to fix Divi's janky portability registration implementation
if ( ! function_exists( 'et_core_portability_register' ) ) {
	function et_core_portability_register( $context, $args ) {
		return true;
	}
}

I haven’t done a thorough deep-dive on what the consequences of this might be, but from what I can tell, it’s only ever going to be doing this when we’re trying to handle ajax actions from within AceIDE… so Divi shouldn’t even be involved, as far as I’m concerned. Preliminary testing (I loaded, edited, and saved a file) has not shown any negative effects, though I’ll update this thread if anything pops up.

And just like that, I’ve got AceIDE working again on this site!

I probably won’t have time to dive into this for quite a while, honestly. Will definitely let you know if I manage to figure this out though.

I think the issue with Divi might be caused by something else. One of my client sites runs that theme and I’m seeing the same behavior, but a different error.

POST https://domain.com/wp-content/plugins/aceide/src/Ajax.php - HTTP 500 (Internal Server Error)

Checking the server logs shows this:

PHP Fatal error:  Uncaught Error: Call to undefined function et_core_portability_register() in /websitename/wp-content/themes/Divi/functions.php:8940
Stack trace:
#0 [internal function]: et_divi_register_customizer_portability('')
#1 /websitename/wp-includes/class-wp-hook.php(286): call_user_func_array('et_divi_registe...', Array)
#2 /websitename/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array)
#3 /websitename/wp-includes/plugin.php(453): WP_Hook->do_action(Array)
#4 /websitename/wp-admin/admin-ajax.php(44): do_action('admin_init')
#5 /websitename/wp-content/plugins/aceide/src/Ajax.php(23): require('/websitename...')
#6 {main}
thrown in /websitename/wp-content/themes/Divi/functions.php on line 8940, referer: https://websitename.com/wp-admin/admin.php?page=aceide

Looks like Divi sets some actions that fire on the admin_init hook, and when AceIDE tries to load that file, things aren’t quite set up right and the server chokes because it doesn’t know where the appropriate functions are located.

This one will take some digging to get to the bottom of… :/

After some digging, I found that it didn’t seem to have anything to do with WPEngine, but rather a security plugin that I wasn’t even running anymore.

Sucuri Security (and many others, I’m sure) have many options for hardening wordpress. One of Sucuri’s, and that they include in their one-click “Harden WordPress” button, applies an option that disables PHP execution in the /wp-content directory. It does this by writing an .htaccess file that sets a “deny-from-all” option to all PHP files in that path.

In my case, I had uninstalled Sucuri ~6 months prior, but the files were still there. Testing with a fresh install and only those two plugins confirmed that the behavior is repeatable, and that disabling Sucuri will also remove the offending .htaccess. No idea why some files were left behind in my case, but I had three different sites showing this issue.

Deleting the .htaccess files in /wp-content solved the issue immediately. In my case, the PHP denial ruleset was the only thing in the file; if you’ve got other directives in there, you probably don’t want to remove everything, just the bit about PHP execution.

Shane — just sent you an email with some screenshots. Thanks for taking a look at this.

Sure — do you have an email address I could send these screenshots to?

Just did some testing, and I’ve still got at least one site that reliably throws this error, even when accessing with a fresh login, caching disabled, in an incognito window.

Same here; after the update to 2.6.0, most (but strangely, not all) of the sites I’m using AceIDE on show identical behavior. More specifically, when attempting to load a file, the POST request to /wp-content/plugins/aceide/src/Ajax.php returns a 403 Forbidden response.

Form data from the dev tools:

action: aceide_get_file
filename: /themes/my-theme-here/css/some-stylesheet.css
_wpnonce: aea216747a