These are not necessary and can pose a security risk.
Read-only archive : Issues · ClassicPress/ClassicPress · GitHub
Author : Dave Jesch
Vote count : 42
Status : open
Tags :
difficulty-moderate
request-remove-feature
Comments
IMHO they are damn well necessary. Esp. when your client doesnt know nothing about the web, not being able to find his SFTP login data. For quick fixes, this really helps a lot.
BTW: people edit and delete core files, no matter what, anyway.
What would maybe do better is a specific switch in the Options / Settings to enable both editors, and set the default state to disabled.
~ posted by Fabian Wolf
One more to disable them by default I was going to suggest this myself, besides being a security risk is used in the majority by support tasks/debug issues.
If someone just forget a semi-colon or cause any other error you will get the WSOD and leave the customer site down till the moment he can reply with any FTP credentials to fix the error caused.
~ posted by Rui Guerreiro
@ Rui Guerreiro - You won’t get a WSOD… all of the editors use code mirror now and won’t save an update anymore if the code is invalid. The only way you can get the WSOD is to upload a corrupt file to your theme or plugin.
~ posted by Jeremy Ratliff
I agree with Jeremy and also consider that now in WordPress they are working on a WSOD detection that disable plugin but was postponed to 5.1 broken-plugin-site-admin.png on Ticket #44458 – Attachment – WordPress Trac
So also ClassicPress will benefit of that.
Also this editor with codemirror and live check of error before save are very helpful on support in website when you don’t have other access.
~ posted by Daniele Scasciafratte
My original thought was to have this feature removed, not disabled. It’s more code that has to be maintained and updated. It could be moved into a plugin however. This way, if someone needs/wants to use it they can install the plugin and edit things. But from a security standpoint, having the code there – even if it’s disabled by default means that the code could still create a vulnerability. So at the very least, disable by default. But preferably remove and make this into a plugin.
~ posted by Dave Jesch
I use the theme editor all the time for child theme css changes, but not beyond that
~ posted by Edward Brodie
A feature plugin would be a much better place for the code editor features. There is a lot of code involved, with a lot of hidden security gotchas, but it is all very separate from the core feature set and goal of ClassicPress as a platform. Making it a plugin would actually allow the code editor to improve faster, as well, as it wouldn’t have to sync development cycles with Core, and wouldn’t have to get all changes approved by the larger team that is mostly focused on other projects.
~ posted by Greg Schoppe
This is one of those things that clearly fit as Core Plugins disabled by default .
Related: Core Plugins Discussion
Huge thumbs down on this idea. Very unusual to not have some type of editor for files that are included with a theme.
YES People break things (that is how I make my $$$)
YES People disable the linecode edit to bypass syntax highlighter
YES etc., etc.
NO I would not want to see the theme/plugin editors disappear as they HAVE a purpose
NO Once you mess with one editor, next will be “Let’s get rid of the Post Text Editor.”
NO How do you see a file without having FTP? (as 85% of user base is)[citation omitted]
If any IMPROVEMENTS or changes were to be dedicated to the Files Editor, it SHOULD be better code check and capabilities honored to a user—not by user_level.
We will not be removing anything from the core any time soon. A better petition is to disable these by default . This petition will be closed.
1 Like