bruandet

You can change the permissions of a file or folder with the chmod command:

Folder:
chmod 0644 /full/path/to/folder

File:
chmod 0644 /full/path/to/file.php

SCP requires some interaction like keys exchange that you can’t emulate with WPTerm, I’m afraid.

What functionality/feature would you like to see in the free version?
Post them here, I’ll happily consider them if they can be implemented.

The plugin is only 6-month old and there’s room for improvements and new features. A lot of changes and tweaks have been done lately based on the feedback and needs of its users.

The error was introduced in the latest version 4.0 of The Post Grid plugin, not in the latest version of Code Profiler. If you install the previous Post Grid version 3.1.5 everything is working as expected.
I recommend to open a thread in the Post Grid’s support forum ( https://www.ads-software.com/support/plugin/the-post-grid/ ) and to show the error log to the developers, I’m sure they will be happy to give you more details about that error and maybe to fix it if they have to.

• This reply was modified 2 years, 10 months ago by bruandet.

If you can post more details about it, that would help to see why it throws a internal server error.

Keep the “5xx server errors…” option disabled for now, try to enable debugging in WordPress and see if there’s anything written to the PHP error log:

1. Edit your wp-config.php script.
2. Search for:
define('WP_DEBUG', false);
3. Replace with:
define('WP_DEBUG', true);
4. Add this line below:
define( 'WP_DEBUG_LOG', true );

Run the profiler and check the log, if any, which will be saved to “/wp-content/debug.log”.
Paste its content here or, if there are too many lines, upload it to https://pastebin.com/ .

After your test, don’t forget to undo the changes to your wp-config.php and to re-enable the “5xx server errors…” option in the “Settings” tab.

It’s optional, you can disable it: go to the settings tab, and uncheck “5xx server errors (500 Internal Server Error, 503 Service Unavailable etc)”.

WordPress sets it.
But you can try to define it in your wp-config.php:
define('UPLOADS', 'wp-content/uploads');

But it will be relative to the ABSPATH constant, which is defined in your wp-config.php. It looks like this:

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
   define('ABSPATH', dirname(__FILE__) . '/');

Is your ABSPATH correct?

Code Profiler uses the wp_upload_dir() function to retrieve the upload folder.
Could you make sure that your configuration returns the right values for the plugin and content directories: https://codex.www.ads-software.com/Determining_Plugin_and_Content_Directories

The data generated by the profiler seems corrupted or empty.
Can you enable debugging in WordPress and see if there’s anything written to the PHP error log?

1. Edit your wp-config.php script.
2. Search for:
define('WP_DEBUG', false);
3. Replace with:
define('WP_DEBUG', true);
4. Add this line below:
define( 'WP_DEBUG_LOG', true );

Try to run the profiler, then check the log that will be saved to “/wp-content/debug.log”.

What is your user role when the errors occur: admin, editor, author, contributor?

That is odd indeed. I tried Elementor and didn’t have any issue.

Can you check what is the AJAX action that triggers the 401 status code? You can see that with your browser console in the “Network” tab (F12 key)

It’s working perfectly.
I will likely release a new version later this week and I’ll add some instructions explaining how to use both plugins.

Did you run the profiler from the WordPress dashboard? It should detect the HTTP basic authentication. That was added to v1.2.

It doesn’t support it when you run it from WP CLI though. I have written the code but didn’t have the time to test it yet. I’ll add it to the next release.

Thanks for reporting the issue.
Since version 1.2, there’s the new custom post input field, hence the list of posts displayed inside the dropdown menu is obsolete now, I’ll remove it in the next version.