The code editor. One for plugins and one for themes. If I were using tracking software, it would register me as rarely venturing into that part of the WordPress administration. I’ve used WordPress for two years and I’ve burned myself enough times by using these code editors that I neglect to use them anymore side from looking but not touching code. The biggest problem I have is that it doesn’t contain any revisions. Also, when you click the save button, it reloads the page and causes the scroll bar in the code window to go back to the top meaning I have to remember which line of code I was editing and also remember the change I implemented so I can remove it if I don’t like the desired effects.
I’ve really come to appreciate using Control Z on my keyboard to undo changes I don’t like. You can’t do a Control Z after you click the save button in the editor which again, brings me back to my complaint of no revisions. When CodePress was introduced, I thought it was cool and a much-needed upgrade over the current implementation. However, I love NotePad++ and the ability to play around with a local copy of my site by editing the files directly within a good editor instead of through WordPress.
It’s my opinion that those who know what they are doing use their favorite tool and then upload the changes rather than the built-in code editor. I’m going to take a guess and say that end users make up the majority of the user base for WordPress and that this user base is not so inclined to use the editor to change code around. Therefor, I’m hoping to hear some valid reasons as to why it should be kept in WordPress.
It is asking for trouble plain and simple. My personal feeling is that it should be removed, if only to discourage live editing. It is so easy to break a site to the extent that you can’t get back into the code editor.
Yeah, those are my thoughts as well. I’ve edited a plugin through the editor a few times and the whole site went to a blank white screen. I had no idea what happened. Had to delete the plugin from the folder to get the site back one. I guess I miss the big red warning label that said edit at your own risk lol.
Thats at least not fully correct with the Plugin editor, If you edit a plugin, it has to pass a no-fatal-errors check before the rest of the blog is allowed to include it.. but thats only for the file being included i guess.
not sure if the Theme editor has anything like that built in.
I occasionally use the code editor for plugins but mostly to just view it myself or copy it into notepad++.
Its a quick go to to edit with especially from the developers point of view, instead of having to open up the folder where it is or accessing the ftp server to then open up the files.
But for the everyday user.. there should be some way to remove or disable it to prevent some sort of mistake from happening.
I think the editor gets disabled if the permissions are too strict so that the files can not be written to or at least, the changes can’t be saved. But if were going to go through all that trouble, why bother having it in the first place.
I use it in the same way — only now and then, as a slightly quicker alternative to FTP. However, I don’t really consider this to be “using” the code editor, because I am not in fact editing code in it.
This may sound like semantic quibbling, but I think it’s an important distinction. Why does WP contain a tool in the admin interface that it cautions you not to use (at least in the case of the plugin editor)? I’mma no get it.
Jeff said:
Sorry… I’ve got a whole lot o’ nothing.
“My personal feeling is that it should be removed, if only to discourage live editing.”
Mine as well. The editor is disabled in MU, so even when I am working on a WP blog, I never think of using it.
I am the person inbetween someone who knows what they are doing and just a regular user. I’m a hacker and I don’t mean that in the cool 90s movie sort of way.
I really like the code editor.
Rhett, and I agree that the more you play, the more you learn, this doesn’t however make sense in a production environment.
It isn’t best practice to work live and we shouldn’t be leading people down a path to sink their own ship down the road.
It would make more sense to have a development blog to check changes before they’re made in production. You still get to learn but you minimize the risk of taking out your site for an extended period.
Although a bit more work up front, it is worth it in the long run.
Best,
Dre
I am also this person and also like the code editor. It’s great for a quick change and I back up often so have copies of all my files.
Taking away a function because some people might use it incorrectly is paternalistic.
I’ve always looked at allowing everyone to live edit as a dangerous proposition. You’re enabling inexperienced coders to explode their site from the admin panel, why? Probably not the best venue to learn how to modify or add a function. 🙂
Purely from a convenience perspective, I’d be willing to bet that only a small percentage of folks use the editor to do minor adjustments, and even a smaller group using it regularly.
I say make the move and off with its head!
The ability to disable the code editor would be good, but getting rid of it is not necessary. I do most of my developing in Notepad++ but there are times when I want to make minor changes with the code editor and see the results without uploading etc. If I had the option to disable the code editor I would have it disabled in most of my WordPress sites (or most of the time in all my sites depending on how easy it was to enable/disable it but I would like the ability to use the code editor for those things that need to go through some quick cycles of testing and tweaking.
I guess I could just completely ignore it and then it’s no longer an issue, but I wanted to throw out the question to the audience to see if anyone else feels the same way. I mean, if the code editor had revisions and didn’t move the scroll bar away from the page and also didn’t do a fresh reload, maybe I’d use it more often but after editing plugin code wrong to many times only to see a white screen of death, I’m done!
You’re not alone Jeff.
I am not a WP user, however after reading your post I will venture an opinion.
Your first impression of the code editor was: “I thought it was cool and a much-needed upgrade over the current implementation…”. I think your first reaction was good one. But you have since come to realize that it has some serious limitations that restrict its usefulness. With this in mind, keeping this tool in WP is open to debate. Instead of writing it off, perhaps you and some others could petition to have the much needed features added to the editor.
Just a thought. Sounds like the editor could be a real boon and time saver in the right hands. Shame to waste all the software development. Any good piece of software should evolve. But users have to fuel that evolution.
I completely agree with you. Adding certain functions would be better then taking it away.
There have been times when I have blown up my whole site using the code editor window anywhere from CSS to plugin editing. I’ve also done on the fly needed fixes using the editing tool on plenty of the sites I run when I am not on a computer that has all my backups etc.
I use it every once in a while when I need to make a minor change to one or two things in my CSS, but I certainly don’t use it for any major work with CSS or with the theme script files. For that I work off my local install of wordpress and use TextMate (Mac).
I specifically only use the Code Editor (plugin or theme editor, correct?) for when I’m helping someone with their website but don’t have FTP access to their files. Most of the time their permissions are set right so that I can save, sometimes they aren’t.
Anyways, I use it to make quick modifications mainly in support of Pods to help them implement it on their site or help track down a bug they might be experiencing. I think it’s a great thing to have, and agree it should just have an enable/disable option in the Settings panel.
Another option is have it disabled by default & have a constant that you set in the wp-config.php file to enable it if you want access to it. I only see it as an easy way to get a copy of a plugin or theme file, for editing on my desktop.
The code editor is a liability, plain and simple. You end up with unversioned code, no changelogs, etc. Then there’s the security aspects. Ultimately, if the code editor works then your security is probably far too loose and your site is at far greater risk of being hacked.
I actually use it as a test for security on any client sites – if it works, they have issues 🙂
“You end up with unversioned code, no changelogs, etc.”
*You* might, but i don’t. I make changes using the code editor and then, as soon as possible, i commit them to my svn repository. Sometimes it’s just much more convenient to use the code editor, but the end result is the same.
I use the code editor more or less continuously. I use it more often than I write blog posts. I edit themes, plugins, hell, I’ve even edited core code with it.
Whenever I’m testing or developing a plugin or playing around with a plugin, I use it to edit the plugin in real time and see the changes in real time.
I don’t develop locally, I develop live, on the server. Living on the edge and all that. 😀
LOL. I’m sure being a developer for over 10 years or so helps you understand WTF you’re doing before you do it.
I also develop live, but I prefer using Gedit (on Ubuntu) which can seamlessly save files over FTP. 😀
Makes sense for you Otto, you kinda know stuff 🙂
My issue is the problems it can pose to people that don’t have your experience and skills, and probably shouldn’t be editing live.
It would make more sense to me to have a live editor plugin vice including it by default. At minimum, have it completely off by default and make users have enable it in settings with a check box or something if they choose to do so.
I used the code editor also more than I post. I do wish there was a way to navigate to subdirectories because many themes have subdirectories.
It would seriously reduce my productivity to have WP remove it.
Maybe a default could be to have it off but a checkbox (like near where one indicates whether one wants WYSIWYG editing) only available to users at the administrator level would be available for the hard-core coders who need frequent access to style.css, index.php, header.php and footer.php files.
I like using the plugin editor for looking at code that seems to do 99% of what I want and then using that to email the code to the plugin author to revise. Plugin authors LOVE it when a simple task is made easier and which benefits their user base.
I use it occasionaly.
I have two issues with it:
1. Can’t insert TABs. I found a plugin that fixes this: Tab Override
2. The page refreshes. This could be fixed by using AJAX. Don’t know of a plugin for that.
Also, be sure to check out this ticket: #11306.
Someone mentioned over twitter that they are using Beta 2 of WordPress 2.9 and the scroll bar remembers its position. Was this a patch committed to 2.9? Do you know of the ticket number?
Not sure when it was added or changed but it does indeed work in WordPress 2.9 Beta 2.
Can’t find anything of the sort.
It sounds simple, but one of my biggest complaints with the code editor is the inability to use tab. In my experience, code done in the editor generally just looks messy. I prefer to edit files in vi.
99% of the time I don’t use it, but it does come in really handy when a friend (or even a new client) needs something minor changed. It’s much more of a hassle explaining to them how to setup an FTP account for me. It’s pretty easy to just create a new WP user account so I can login and make a quick change.
I’ve never run into the problem of a client messing anything up because of the editor (I have! but that was my fault, not the editor’s).
Do not use the code editor, prefer to edit files on my local computer, test the changes and then upload them to the live server. And yes, I am actively use Subversion and Bazaar to be able to roll back later if my changes mess something up.
I haven’t used the code editor for as far as I can remember. Just prefer coding in Notepad++
Then I upload it via FTP and test it out.
I personally like the editor, (tho I miss the code highlighting that was in one of the betas). For most things I use ftp, but sometimes I just need to edit something small an safe, or get a reference from another site, the editor is just plain useful. It prolly should only be available to admins tho (not sure if it already is).
I don’t have a big problem when people use the editors every once in a while on a development site, but I do have a problem with people using it as their standard editor or with people using it on live sites. Personally, I never use the file editors on the back-end. It’s just asking for trouble.
The reason to not use it as the standard editor is multi-fold:
– There isn’t the ability to undo the changes you’ve done if you don’t know what changes you’ve made as others have pointed out.
– Developing in a text box doesn’t offer as many tools to improve efficiency as most standard text and code editors offer.
– If a mistake is introduced that kills the WP execution stack, a different editor now must be used to correct the mistake.
There are also many reasons to not use it on a live site, but the biggest one is site reliability. If I make a mistake and bring the site down, I then have to connect via SSH, FTP, or other method; navigate to the location where the error was introduced; and pray that I can fix it quickly. Imagine that for some reason my server access doesn’t function; now I’m screwed. Of course, if I were already editing through some method other than the WordPress back-end, then I can quickly hit ctrl+x until all my changes are gone, save the file, upload the file if necessary, and have the site back (hopefully) before anyone notices. Additionally, having already loaded the file through some means outside of the back-end ensures that I have the server access necessary to undo the mistakes.
The irony of the situation is that the people who most often use the back-end editors are the same ones that have a poorer understanding of coding in general and are thus more likely to introduce coding mistakes.
I don’t think that the back-end editors are going anywhere anytime soon. I do think that they need to be improved to do some type of validation to ensure that broken code isn’t permitted to be saved.
I think it should be kept in because of Google’s Chromium OS.
All functionality is moving online. The code editor doesn’t need to be removed, it needs to be upgraded.
I think perhaps WordPress is trying to be too much to too many.
Perhaps using something along the lines of http://phpanywhere.net/ would be a better approach. At least that way you can change the file back when you break it. And you will.
I’m a bit torn though. Do we continue to improve the Code editors and add features such as revisions, line numbers, etc or do you leave it as is and still use a desktop editor? A part of me does not understand why I would want WordPress to have a built in NotePad++ type editor. But if the editor is not improved, then why leave it in WordPress.
I think WordPress should get rid of the editor as it is plugin material in my opinion. We can have a plugin that does syntax highlighting and revisions but we don’t need this bloat in the WordPress core.
+1
There are a lot of experienced users using it daily it seems but why include it in core?
I think it’s plugin material or have it off by default with a check box option to turn on in the admin panel by admins.
I use the functionality in the *template* editor to troubleshoot changes/edits quickly without the rigamaroll of FTP uploading/refreshing. But editing plugin code on the fly? No thanks. In the current incarnation it’s just plain unsafe, even under the best of circumstances.
If the functionality of the editors is pushed to the forefront it’d be solid to add in a “$disable_live_editor” var.
The code editor is one of my most used features of WordPress. I always back up my templates, but whenever I have an idea, it is great to go to my sandbox WP install and play with a template or a plugin.
That said, I do agree that it should have a way to disable it by default to keep novice users out of trouble AND I would like to see some work done on future versions of the code editor to make it more user friendly.
Possibly even turn the Code editor into a standard Plugin like Hello Dolly, so that it can be turned on and off but still allow development separate from the WP version? That would be my wish.
I use it as a quick way to view code, not to edit it. I hope THAT ability continues, but I won’t often use the editing part, for the same reasons listed above.
The ability to peek at code: I use it most to view read-me files when plugin editors forget to leave instructions in obvious place, to look at specific pieces of php code, and to examine theme files that I may have forgotten about…and the occasional easy quick-fix.
Notepad++ and ftp upload work best for me for real editing.
So, ultimately: don’t get rid of it, but I don’t care if it gets upgraded.
I use the built in code editor constantly.
I’m always tweaking something. And usually from different computers.
It does suck though. Jumps around with copy and paste. I would love to see this thing upgraded.
Agreed it should be updated not destroyed.
No doubt a very low standard code editor which is built in with wordpress.No syntax highlighting.I dont use it
The question isn’t “Do you use the code editor?” the question is “How techie are you?”. The more of a techie, the more you will use the code editor because it gives you exact control.
And FYI – I use the code editor exclusively. Yes, I am a techie.
I suspect the opposite is true.
I think more technie people would be far more likely to use well developed tools and workflow in favour of a quick hack solution which is really what the editor offers.
I’m using it all the time on my test sites, since the colleagues that I’m working with are scattered around the World and we need to see the changes that each other do in real time. Of course we make backups all the time, but we will need to move to another CMS if ever it is removed.
There is a way to make it work in Mu, however it’s a loss in productivity to do it every time so we are now using something else for community websites most of the time.
I love it!
If it goes I hope there will be a plugin to put it back.
I constantly use it when developing a new WP theme. I always ‘select all’ then copy and paste to G-edit then hack the code and things are usually good. If they’re not I have the copy and it’s really quick and easy to revert, plus there’s no messing with FTP (which I despise for it’s lack of speed and unreliable nature, at least with larger files).
I say if people mess in areas where they are out of their depth, they either learn fast or go down crying, but it’s their choice and after all, open source is about choice is it not?
I use it a lot for small changes. I open two browser windows with code in, then if my changes mess anything up I can resave the original code over my changes in the second window. Some of the blogs I manage have unwidgetized sidebars and it’s useful for making small tweaks to them.
Btw is there a page/site somewhere explaining how to set up a local copy of a WP site so you can test changes locally before uploading them?
Does a video tutorial work for you? If so then http://wordpress.tv/2009/01/26.....ampserver/ covers it. If not I guess I could write up a post on my blog to do it using XAMPP on a portable drive. You know what I will work on that it will take a bit & may take a day or two to get posted.
Thanks Joe. I prefer text instructions if both are already available, but don’t write a post just for me – I’ll watch the video tutorial.
Well it wasn’t just for you & after finishing it I do not want to do it with that flash drive I used ever again. It was way to old & thus painfully slow. But I did post it over at http://blog.v2joecr.com.nyud.n.....ble-drive/
Dang I guess I’ll just have to disable that plugin. it’s at http://blog.v2joecr.com/2009/1.....ble-drive/
Joe, I just watched the video – thanks, that was very helpful.
i do the exact same time here. one editing n save to reload pages. another copy as the unofficial backup =)!
editor must stay! for the sake of sanity! i remember using wordpress back then.. eons ago when editing was pure ftp uploading. it was a PAIN to make minor edits.
Yo no uso el editor, es muy lento para mi, y no se pueden volver los cambios para atras, asi que si haces algo mas te arrepentis despues. Uso dreamwever to edit the files and despues los subo por FTP. Saludos
Perhaps the solution is simply to separate the editor from WordPress to the extend that it will run without loading any plugins or themes. That way the edits can’t break the editor.
I’m not a big fan of the editor, but I don’t think it should be removed. Here’s why:
WordPress has become increasingly easy to use–which I think is a good thing. But I’ve noticed over the last 6 to 8 weeks or so, more of my theme customers don’t know what FTP is. They use the theme uploader and plugin uploader exclusively to add new plugins and themes. I used to send people an updated file when they asked for a small change to a theme (showing the excerpt instead of the content or a small css change). Now that most don’t know about FTP, the easiest way is to get them to paste the code into the editor. It is a risk for all the reasons laid out above, but given the level of experience it is the simplest solution.
Instead of removing the editor, let’s just make it better–revisions, undo without keyboard shortcuts, scroll bar memory and so on. I’m going to keep using Coda, but if we could make the editor work a bit more like a desktop program, I believe it would benefit the whole community.
I use the Theme Editor ALL THE TIME! 🙂 (sorry for shouting~)
I manage a dozen sites and probably once a day I go in and make changes to most of the sites. I understand the worry that problems may happen and then there is no “Control Z”, but IO do a daily backup of all my files on my VPS and I can easily retrieve those in case of a major error.
I really hope WordPress does NOT remove the ability to edit Theme and Plugin files.
keep it! everytime i change a them, i use it like there’s no other code editor! it’s on the fly and great for doing minor changes. the idea of using notepad, and then reloading it sucks.
I use the code editor for quick edits, but 99% of the time I edit offline in Coda and upload the changes.
I use the code editor a lot, and I would be really sorry to see it go. It is mostly the css file that I edit, and it is a very useful function, since I make my own themes. All the fine tuning happens on the fly, in the editor.
I don’t agree with any sort of nursemaid/nanny attitude that dictates that you must remove any function that can cause trouble. I mean, we have not yet outlawed cars, and they are the cause of many deaths every year. Yet they are also very useful machines. So is the WordPress code-editor!
Used it today, glad to have it when I need it.
It’s really indispensable for small, fast tweaks.
For big changes and development, I have svn, bash and rsync to manage deployment. That’s a lot of hassle when you’re whipping out some test code for a client.
I hope it stays in.
I use it rarely. I make edits on my local subversion folder and upload via FTP. For some weird reason, I find it a big hassle going back in the other direction.
unless i’m forced to edit something on the fly i don’t use it! but it would be better to enhance it and give the ability to create a new template files that you can write the markup easily.
Also would be great if it Auto format the code or something so you don’t get lost with your code 🙂
Thanks,
Mohammed
Code Editor has been a lifesaver for me when I have to do edits at the office and am blocked from accessing my sites server. Let it be disabled for those in fear but do not eliminate it. Some of us need it.
Running a Spanish language site, the code editors are the only way I found to include special characters (like accented vowels), what I can’t do with other editors. Maybe someone can suggest another quick way to do that. Meanwhile, the code editors are quite useful to me.
If you’re using special characters in HTML, you should be using the HTML entities – i.e., codes starting with “&” and ending with “;”. Here’s a list of them: http://www.webmonkey.com/refer.....Characters
If you’re using Windows I recommend Notepad++. For any text file be sure to use UTF-8 encoding. Go to the Format menu and select UTF-8 without BOM. Any good text editor should have a UTF-8 mode.
I use the code editor, but probably not the way the developers intended.
I generally edit the files on my computer using a text editor, and then cut and paste into the WordPress code editor, which I find easier than using FTP if I am only modifying a single file.
Note that I would only do change/development work like this on a live site when it has very low traffic.
Cheers,
Stu.
Code editor? Get rid of it.
Want to make a quick live change? Mount your web hosting directory on your filesystem (e.g. as a drive letter in Windoze). Or get really serious and learn ssh and vim. 🙂
As a web developer who’s constantly on the move, I pretty much rely on the WordPress Editor feature. I’ve started deploying some of my non-Blog format clients with WordPress as well for this reason – I can make near-real-time changes to the Stylesheet or specific Pages from anywhere – I can literally be on-site with one client while updating something for another, or pull into a Tim Horton’s and make the changes from my PDA. I assume if they ever strip this feature from WordPress, it’ll just be a matter of seconds before it’s published again as a Plugin anyway.
I use the code editor a lot. It’s a lifesaver sometimes!
I develop a site initially on my local development server, but when i’m ready to let the client have a look at it, i move development to my live server and give the site a temporary URL. That way, the site is freely available to the client and i can make changes and they can check them out.
Under normal circumstances, i mount my home directory at the server on my local machine using sshfs and work on it using the geany code editor as if it was local files. I regularly commit new work to my subversion repository.
However, for security, my web service requires me to email them to request ssh access (which gets granted for 3 hours at a time) and sometimes it can take them a while to respond. If i want to make a quick change to a site without the hassle of getting ssh enabled, i use the code editor. Then, next time i’ve got an ssh connection up, i commit the changes to my svn repository.
If the code editor was removed from WP, i could edit the files using the hosting service’s web-based file manager, but that would be much more hassle.
I think the code editor should be kept. It’s probably worth doing the work to enhance it, too. If i ever get enough spare time i might even have a look at that myself….
I rarely or never used WordPress’ code editor. Although I don’t think it is a complete waste because once upon a time when I was at friends house and I needed to make a quick change to my site it came in handy but other than that I prefer using coda for all my coding needs 🙂
Never used it but I also think it should be kept for people who have to look at something fast and easy
Well, if you are going to have a code editor, make it work and make it a good one.
I would use the WP editor given that I am going more and more “to the cloud” and less and less toward PC based apps (like Dreamweaver). What I really want is to log into my WP site and make changes to templates and css files with a good, solid editor with syntax highlighting etc. If I had this, it would be bye-bye Dreamweaver.
Right now, the current editor is a “last resort” editor. I sure would like something decent!