shanept

Hi wpfan1000,

AceIDE already has inbuilt versioning!
Check under the plugin/backups directory.

Kind regards,
Shane Thompson

I would definitely be interested in looking into this further. If you could facilitate this, I would definitely appreciate it.

Hey Tanner,

Have a look in your wp-config.php for the following:

define(‘DISALLOW_FILE_EDIT”, true);

If this appears, it is the reason for the menu item not appearing.

Otherwise, I can only imagine this is a bizarre bug.

Hi Tanner,

Great question. Let me outline the logic behind determining whether one key access the menu.

First check:
A test for the value of the “DISALLOW_FILE_EDIT” constant. If this is true, the editor can not be used. However this may be overwritten with the “aceide_override_disallow_file_edit” filter.

Second check:
Simple referrer check.

Third check:
If the site is multisite, the user must have the “manage_network_themes” capability. Otherwise, they require the “edit_plugins” capability.

By default, these capabilities are assigned to an administrator, or in the case of a multisite it is a super admin.

Hi Sam,

If I may direct your attention to the line where the error occurs, you will see from the error that ‘$this->git’ is NULL.

‘$this->git’ is defined here or here. As you can see, these lines are both commented out, therefore there is no ‘$this->git’! The reason for this, is that git is still a development feature, and as I currently have no use for it, I haven’t been developing it. (I would be very happy to accept a pull request though!)

Sorry about that! If you’re keen to try get it working, please do feel free to play around and let me know how you go.

Hi jfacemyer,

Sorry for such a late reply – I will be attempting to fix this shortly.
If you continue to have issues after you update the plugin, please let me know.

Thanks,
Shane Thompson

Hi dug43543,

Unfortunately the problem with this is that it is related to an external library that we are pulling in.

At the moment, the best I can do will only remove some warnings, it will not solve the errors you are seeing.

However if I remember correctly, this is specifically for a feature that is not enabled without WordPress debugging, so I can’t see it affecting the functionality of the plugin, or the site – is this not the case?

Thanks,
Shane Thompson.

Hi primo1983,

This is a different underlying error – perhaps with a similar outcome.

Could you please provide the exact error from the error log that you are experiencing? Removing the constant should have broke things…

Thanks

Hi primo1983,

An HTTP 500 error does not indicate a file is missing. The file is definitely there, however there was an error running the code on the server.

To understand what the error is, we will need to see what the error is in your error log.
Are you able to provide the error from your error log?

Thank you,
Shane Thompson

Ok, that’s bizarre for sure… I’ve got no idea why it might be doing that, beyond a server config issue, at this point. This is the first occurrence of this that I’m aware of.

Would you mind me having a look at your website myself to track down the issue?

Wow, that’s very weird… I’m thinking it’s related to output buffering.

Do you have any other way of modifying the code in 2.6 Ajax.php?

I’d like to see what happens if you disable output buffering – that is the whole initial if statement.

See https://github.com/AceIDE/editor/blob/master/src/Ajax.php

As you can see, we are using admin-ajax.php, however starting output buffering first.

That’s interesting…
Are you able to look at the network log in your browser and tell me whether the server is sending the full file in 2.6?

So all I can see is that it’s missing whitespace – is that correct?

Hi again,

Yes I understand, he is referring to server-side filesystem permissions.

I can only assume you are unfamiliar with the Linux filesystem – if this is not the case, sorry in advance.

The plugin is attempting to include /wp-admin/admin-ajax.php whereas it should be accessing /wpcom-19758243/wp_admin/admin-ajax.php.

The equivalent paths in windows would be:
C:\wp-admin\admin-ajax.php
and
C:\wpcom-19758243\wp-admin\admin-ajax.php

Obviously, /wp-admin doesn’t even exist, but your WordPress installation can’t even see folders in / – this is why your server admin as saying we don’t have access. He’s spot on, we don’t have access there.

I’m not trying to figure out why we can’t read that directory. I’m trying to figure out why it determined that this is the directory to be reading from, when it should be under the /wpcom-19758243 directory. Do you agree/disagree or not understand this?

There is obviously a divide in our thinking here as to what we are trying to achieve. I want to make sure 100% that we are on the same path.

In regards to wp_localize_script, and any other WordPress-specific functions for that matter, they are not an option. They don’t even exist until we have included the admin-ajax file.

Thanks,
Shane Thompson

Hi Oliver,

Scrambled code? That’s a new one… Files missing could simply be an issue with the WordPress plugin update, if you mean files are missing? Did you try the update more than one?

Thanks
Shane Thompson