Make WordPress Core

Updates from Andrew Ozz Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Ozz 9:36 pm on February 9, 2012 Permalink  

    Team update: Tableteers 

    Cycle ending on February 22.
    (George Stephanis and Zach Abernathy)

    1. Admin Left Nav Menu Scroll Independently ( Enhancement )
    The idea is for the Main Left Nav to scroll independently of the body, and metaboxes on the right to create the most usable interface for tablet users. This will create more of an “app” effect best for navigating and using the WordPress admin without the use of an actual app. It was decided not to go this way in #19994.

    2. Clean Up Touch UI for Left NavMenu / Flyouts ( Bugfixes )
    While the flyout is mostly usable in it’s current state, it is not as intuitive as it needs to be for the best user experience. They are ineffective at best on the Kindle Fire’s Silk Browser, but work pretty well on the iPad. We need to examine all target devices to ensure interactivity is supported cross-device.

    3. Possibly add support for dragging of meta boxes
    In the desktop version of WordPress a user has the ability to move metaboxes around to customize their interface. However, touch-and-drag support is not as intuitive on a tablet. There are possible work-arounds that need to be explored. Alternately, there is the possibility of pre-determining the number of columns and not support drag-and-drop.

    4. Dashboard and write screen columns (with @media)
    Determining the number of columns that are present in landscape view versus portrait view. This would need to be tested on a per device basis to determine the optimum number of columns. In WP 3.3 this effect was generated via JS. We should be able to yield better performance by handling this via CSS.

    5. Resolve Amazon Silk Browser ( Kindle Fire ) WYSIWYG Incompatibility
    Currently, the WordPress WYSIWYG (TinyMCE) does not work in the Android Fire Silk Browser, but it does on the native Android browser. This is due to the Silk browser still not supporting the `contentEditable` attribute properly.

  • Andrew Ozz 6:47 am on September 23, 2011 Permalink
    Tags: ,   

    Javascript changes in 3.3 

    Now that WordPress 3.3 is in feature freeze, it’s time to have a look at some new Javascript goodies for developers:

    • jQuery 1.6.4 and jQuery UI 1.8.16. And that’s the full UI including widgets and effects. This will make it a lot easier and simpler for plugins using UI components that are not used in core as they will be able to just enqueue whatever they need.
      Note: there is a known bug/regression in UI Draggable since version 1.8.13. When connecting a draggable item to a sortable container, the HTML ID of the item is removed, #17952.
    • WordPress Editor API. This is an updated API for both TinyMCE and Quicktags that outputs all parts of both editors in the same way as used on the Add / Edit Post screens, #17144. Plugins will be able to use the WordPress editor anywhere including the Visual/HTML tabs and the links to upload files and show the media library.
    • Quicktags refactoring. This was necessary in order to make it fully multi-instance compatible, #16695.
      Note: if your plugin adds a Quicktags button please enhance it to use the new methods in quicktags.js.
    • New multi-file uploader. Plupload was included as a result of Google Summer of Code project, #18206. It’s more stable and has a lot more features as well as chooses the best available interface that the current browser supports: HTML 5, Silverlight or Flash.
      Note: two actions that were specific to SWFUpload were renamed and there is a new filter ‘plupload_init’ that gives access to all initialization options.
    • Other enhancements: wp_enqueue_script() now works mid-page and prints the late enqueued scripts in the footer #9346, wp_localize_script() uses json_encode to properly escape and output all strings, #11520.
    • Scott Kingsley Clark 2:18 pm on September 23, 2011 Permalink | Log in to Reply

      We were using a very early version of #2 and it’s been working great, excited to integrate the full 3.3 Editor API and have it work to the full extent we and plenty of other hungry developers have waited for 🙂

    • Conor Hughes 2:00 pm on September 26, 2011 Permalink | Log in to Reply

      Question about plupload, Does it include the option to spilt the upload in to samller chunks? So basicly does core included all the feature of the wplupload plugin https://wordpress.org/extend/plugins/wplupload/

      • Andrew Ozz 7:17 pm on September 28, 2011 Permalink | Log in to Reply

        No that’s not enabled by default but can be set by a plugin. Seems only Chrome handles splitting the file into chunks properly at the moment. It would have been nice to remove the upload size limit 🙂

        When more browsers start to support this reliably we can enable it by default, probably 3.4.

        • Conor Hughes 7:39 pm on September 28, 2011 Permalink | Log in to Reply

          Currently using the plugin and file spliting works in opera and Firefox 6+, However I am using the flash runtime not HTML5.

    • Stas Sușcov 7:47 pm on September 27, 2011 Permalink | Log in to Reply

      Great news on Editor API and `wp_localize_script()`!!!

    • Jason Penney 8:05 pm on September 28, 2011 Permalink | Log in to Reply

      Glad to see the full jQuery UI (also, looks like I picked the correct script names in Use Google Libraries way back, so I won’t need to make changes in there when 3.3 comes out).

    • Joerg 9:59 am on September 30, 2011 Permalink | Log in to Reply

      I hope the TinyMCE editor will offer tables in WP by standard so that I would not need to install any plugins anymore….

      • Andrew Ozz 4:10 pm on September 30, 2011 Permalink | Log in to Reply

        No, the default TinyMCE configuration in core has not changed. Most functions related to it were combined in WP_Editor class.

    • Max 9:14 am on November 4, 2011 Permalink | Log in to Reply

      Too late for jQuery 1.7?

  • Andrew Ozz 11:40 pm on July 1, 2011 Permalink  

    To all that responded to the idea for CSS cleanup in 3.3: have your say at The big CSS overhaul in 3.3, part II.

  • Andrew Ozz 5:41 pm on May 25, 2011 Permalink  

    jQuery updates in WordPress 3.2 

    There have been two major releases of the jQuery library during this release cycle. WordPress 3.1 includes jQuery 1.4.4. WordPress 3.2 will include jQuery 1.6.1. The new jQuery is faster and better but also has some major changes. The two most important changes that all plugin and theme authors must test for are:

    • Selectors that include [property=value] now require quotes. So

      will not work. It needs to be

    • All ‘selected’, ‘checked’ and ‘disabled’ properties should use the new .prop() method introduced in jQuery 1.6 instead of .attr(). In most cases .attr() will still work but for example
      .attr('checked', '')

      fails (that used to remove the checked=”checked” from checkboxes). More details and a list of all affected properties are on the jQuery’s blog.

  • Andrew Ozz 7:54 pm on April 27, 2011 Permalink
    Tags: ,   

    Calling all CSS “Gurus”, well everybody that is interested in CSS to voice their opinions about The big CSS overhaul in 3.3.

  • Andrew Ozz 10:35 pm on April 25, 2011 Permalink

    The Distraction Free Writing mode has been in trunk since yesterday. Would appreciate comments, suggestions, opinions, etc. Bug reports should probably go on #17136.

  • Andrew Ozz 8:10 pm on April 4, 2011 Permalink

    To the Directors of White Space 

    Dear Sirs,

    It has come to my attention that our White Space is running wild. Would it be possible to tame that beast back into submission please.

    Seriously, I would like to propose adding another rule to the coding standards: when outputting HTML directly, leave all white space in PHP. Currently we do something like this:

    if ( something ) {
        <div id=...>some more</div>
        <div id=...>even more</div>

    That’s all nicely readable on the PHP side but the outputted HTML is surrounded by quite a bit of redundant space. What I’m proposing is to stop/start PHP immediately around the HTML:

    if ( something ) {
        ?><div id=...>some more</div><?php
        ?><div id=...>even more</div><?php

    This doesn’t impact the readability on the PHP side and produces “tight” HTML with no white spaces as it should be for production. In fact the HTML source would be “pseudo-minified”.

    Of course the readability of the HTML source will be affected but not that much. Currently our HTML output is all over the place which makes it pretty hard to read. Considering that most people never look at the HTML source directly any more thanks to FIrebug and friends and all coding oriented text editors have a function to reformat HTML, I believe outputting “minified” HTML is an advantage. This also reduces the size of our output from 3% to 15% depending on the page.

    Of course I’m not proposing for everybody to rush and reformat the whole codebase if this is accepted. But we can apply it to new code and clean up functions that are being patched for other reasons.

    • Ken 8:20 pm on April 4, 2011 Permalink | Log in to Reply

      This would be fine with me, I also use firebug when examining html.

    • Joseph Scott 8:25 pm on April 4, 2011 Permalink | Log in to Reply

      Wouldn’t it be better to optimize for the code that is read more often (PHP)? For HTML there are plenty of options to minify automatically if you want to go that route.

      • Alex M. 8:44 pm on April 4, 2011 Permalink | Log in to Reply

        This is my thoughts as well. While pretty HTML is nice, pretty PHP should be the priority IMO. Stepping into PHP just to step right back out again on the next line seems like a waste and makes it a lot harder to read.

        As for size, if that’s a concern then gzip should be used.

      • Andrew Ozz 8:55 pm on April 4, 2011 Permalink | Log in to Reply

        Yes, we can minify the HTML automatically but that’s just another (although minimal) overhead. IMHO if we leave all white space in PHP we are optimizing both at the same time.

        Our code is already pretty much optimized for readability on the PHP side. If we accept this as coding standard, it would enhance the PHP side a bit (as we won’t have to think about HTML output formatting at all and can place it anywhere we need) and also enhance the HTML output a lot.

      • Andy Skelton 9:07 pm on April 4, 2011 Permalink | Log in to Reply

        I agree with Joseph. I spend so little time looking at the HTML output that I couldn’t care less what whitespace there is. When I’m looking at PHP, I don’t want to have to look at the beginning and end of every line. That’s even worse than reading a long column of echoes.

      • Andrew Nacin 11:17 pm on April 4, 2011 Permalink | Log in to Reply

        I agree with Joseph and Andy as well.

      • Brian Layman 2:28 pm on April 6, 2011 Permalink | Log in to Reply

        I’m in this camp too.

        Plus this may appear moderately readable with two lines but once you get into more it doesn’t hold up nearly as well. I’d rather be consistent in our handling and also save 7 bytes per line of code.

    • Jon Brown 8:36 pm on April 4, 2011 Permalink | Log in to Reply

      Isn’t what you’re proposing the opposite of the existing coding standards which are to open/close php around the actual PHP? More like:

      if ( something ) { ?&gt;
           &lt;div id=...&gt;some more&lt;/div&gt;
           &lt;div id=...&gt;even more&lt;/div&gt;
      &lt;?php }

      Which is compact and doesn’t needlessly open and close php (although I’m pretty sure that’s been shown not to be a performance issue, right?)

      • Ramoonus 12:33 pm on April 5, 2011 Permalink | Log in to Reply

        this is what I prefer, much easier to read
        and most programs can do color coding with this format

    • Mike Schinkel 8:50 pm on April 4, 2011 Permalink | Log in to Reply

      Here’s a question I don’t know the answer to: Is there any performance penalty for excessive context switches between PHP and HTML? Also, rather than context switching, why not use HEREDOCs instead?

      • Andrew Ozz 8:59 pm on April 4, 2011 Permalink | Log in to Reply

        As far as I can tell, no. No performance penalty for switching in and out of PHP at all. IMHO HEREDOC is quite hard to read and is inflexible in many cases.

    • scribu 9:06 pm on April 4, 2011 Permalink | Log in to Reply

      We should avoid context switches, not for site performance, but for developer performance, as Joseph Scott already mentioned.

      Adding more characters to reduce whitespace doesn’t seem like a sweet deal to me. A standard in this area would be good, but not that one.

      How about:

      if ( something ) {
          &lt;div id=...&gt;
          &lt;div id=...&gt;&lt;?php inline_call(); ?&gt;&lt;/div&gt;

      Multi-line blocks should never be indented.

      • Alex M. 9:09 pm on April 4, 2011 Permalink | Log in to Reply

        This is how I write and prefer code.

      • Andy Skelton 9:12 pm on April 4, 2011 Permalink | Log in to Reply

        I recently banished all thoughts of pretty HTML and decided to focus on PHP indentation. So I indent the PHP tags. Here’s my example:

        if ( $lines ) {
            &lt;div id=&quot;lines&quot;&gt;
            foreach ( $lines as $line ) {
                &lt;p class=&quot;line&quot;&gt;&lt;/p&gt;
    • Ken 9:09 pm on April 4, 2011 Permalink | Log in to Reply

      Alternatively, we can recommend NOT using indents for html blocks, but rather line-breaks and comments:

                  if ( something ) { ?&gt;
      &lt;!-- #someid --&gt;
      &lt;div id=&quot;someid&quot;&gt;some more&lt;/div&gt;
      &lt;div id=...&gt;even more&lt;/div&gt;
      &lt;!-- /#someid --&gt;
                  php }

      I’d just be happy with any standard.

      • Brian Layman 2:30 pm on April 6, 2011 Permalink | Log in to Reply

        I imagine my preferred standard of making the HTML indented to the correct level when the HTML source is viewed would be generally hated by all 🙂

    • miqrogroove 9:24 pm on April 4, 2011 Permalink | Log in to Reply

      The only time this white space has ever mattered to me is when dealing with textarea elements, which have a required trailing linefeed. At any other time, I would prefer the former syntax for simplicity and let the HTML look slightly out of alignment. I would never try to minify my HTML.

      • Ken 9:30 pm on April 4, 2011 Permalink | Log in to Reply

        There was a trac ticket a while back about white space between Nav LIs that caused styling issues… He was setting the menu items to display: inline. That and your textareas are the only things I can think of.

    • demetris 10:12 pm on April 4, 2011 Permalink | Log in to Reply

      I think the gain in size is not worth it because, when the document is gzipped, the reduction in percentage is much smaller: 2 or 3 percent at most. (Which, in absolute numbers, is an even smaller gain.)

      My personal preference at present is to always stay in PHP mode. I use echoes with a line feed at the end of the string. So, the only white space in the generated HTML is line feeds. (One reason I started using this style is that HTML highlighting with a PHP document distracts me.)

      • Andrew Ozz 10:33 pm on April 4, 2011 Permalink | Log in to Reply

        Agreed. Assuming that most hosting companies gzip HTML by default the gain will be even smaller: about 0.1% and under as white space compresses extremely well.

      • Jan Fabry 6:47 am on April 5, 2011 Permalink | Log in to Reply

        Indeed, I also prefer to stay in PHP mode. With this proposal the difference will be even smaller, so if there would be a change, I propose it is to PHP-with-echo everywhere.

    • arena 10:59 pm on April 4, 2011 Permalink | Log in to Reply

      ok for me and please please remove the trailing and useless ?> in most wordpress php files

      • Peter Westwood 7:15 am on April 5, 2011 Permalink | Log in to Reply

        It’s not useless – it is good practice in my opinion and makes it easier to identify when people have uploaded part of a file by FTP

        • Mike Schinkel 7:21 am on April 5, 2011 Permalink | Log in to Reply

          I’ve seen whitespace after a trailing ?> cause syntax errors. I’ve never seen those same syntax errors occur when there is not a trailing ?>. FWIW.

        • Peter Westwood 7:24 am on April 5, 2011 Permalink | Log in to Reply

          Syntax errors seems unlikely, Headers already sent is probably what you saw.

        • Mike Schinkel 7:28 am on April 5, 2011 Permalink | Log in to Reply

          Possibly. Either way it was a fiddly error that can take a while for many people to track down. Again, FWIW.

        • Dion Hulse (dd32) 8:50 am on April 5, 2011 Permalink | Log in to Reply

          Mike: Thats the exact reason why user editable files in WordPress don’t have the closing php marker (wp-config-sample.php and themes functions.php)

          But for all other files, no user should edit them, so its a useless argument there

        • Mike Schinkel 8:57 am on April 5, 2011 Permalink | Log in to Reply

          @dd32 – Although it’s not worth debating as an attempt to change the opinions of the core team related to the source files in WordPress, as a point of note it is not completely useless.

          People accidentally modify files all the time. If they open a core file to learn what it does but accidentally add white space to the end they can spend quite a bit of time trying to figure out why their site code now fails although they can’t “see” any difference.

          Again, FWIW.

    • arena 11:28 am on April 5, 2011 Permalink | Log in to Reply

      having or not having a ?> at the end of a file do not mean you have reached the end of the file ….
      then change the
      trailing ?>
      /* end of file */

    • John James Jacoby 1:22 am on April 12, 2011 Permalink | Log in to Reply

      I’m against the grain with everyone here. Go figure. 🙂

      I think having pretty HTML output is important, because scanning through randomly indented HTML output is as irritating as scanning through randomly indented PHP. Call me old school, but I miss the days of having poetically formatted HTML when viewing HTML source on a site. 🙂

      I also prefer not to echo out HTML from inside PHP, and rather close out of PHP and output raw HTML. PHP is a scripting language that essentially provides logic to HTML. Using it to output complete lines or blocks of HTML seems counter-intuitive to me, so it’s reserved in my toolbox for special cases where I may want to filter that chunk of HTML through a WordPress filter.

      This was one of my original kvetches about WordPress when I stopped lurking and started posting in the support forums. (Embarrassing reading my tone back then as an outsider to the community.)

      The problem arrises from having tabs in front of the PHP open brace. It’s good for PHP code readability, but bad for HTML output readability.

      This example taken from index.php of twentyten:

      &lt;?php get_header(); ?&gt;
      		&lt;div id=&quot;container&quot;&gt;
      			&lt;div id=&quot;content&quot; role=&quot;main&quot;&gt;
      			/* Run the loop to output the posts.
      			 * If you want to overload this in a child theme then include a file
      			 * called loop-index.php and that will be used instead.
      			 get_template_part( 'loop', 'index' );
      			&lt;/div&gt;&lt;!-- #content --&gt;
      		&lt;/div&gt;&lt;!-- #container --&gt;
      &lt;?php get_sidebar(); ?&gt;
      &lt;?php get_footer(); ?&gt;

      …should really be…

      &lt;?php get_header(); ?&gt;
      		&lt;div id=&quot;container&quot;&gt;
      			&lt;div id=&quot;content&quot; role=&quot;main&quot;&gt;
      			/* Run the loop to output the posts.
      			 * If you want to overload this in a child theme then include a file
      			 * called loop-index.php and that will be used instead.
      			get_template_part( 'loop', 'index' );
      			&lt;/div&gt;&lt;!-- #content --&gt;
      		&lt;/div&gt;&lt;!-- #container --&gt;
      &lt;?php get_sidebar(); ?&gt;
      &lt;?php get_footer(); ?&gt;

      The differences being the whitespace before the opening and closing PHP braces is gone, and there is an additional empty line before and after the context switch to ensure the output of get_template_part() has breathing room. In the above example, the next problem is that loop.php starts out only indented 1 tab in, rather than 4, which starts the cycle of messy HTML whitespace over again.

    • John James Jacoby 1:35 am on April 12, 2011 Permalink | Log in to Reply

      Maybe we should write a plugin to format the HTML output for us?


  • Andrew Ozz 9:14 pm on December 3, 2009 Permalink  

    WordPress Developer News: WordPress 2.9 Beta 2 

    WordPress 2.9 is currently in beta and is expected to be ready in several weeks.

    Major new features for developers:

    • comments meta table
    • improved support for custom post types
    • register_theme_directory() for additional theme locations
    • back-ported JSON encode/decode for both PHP and JavaScript

    and for users:

    • oEmbed support
    • “Trash” for posts, pages and comments
    • post thumbnails support
    • basic image editor

    More details are available in the Codex https://codex.wordpress.org/Version_2.9 and on trac.

    New feature in the plugin repository: logged in users can enter compatibility information about all plugins – works / doesn’t work for several recent versions of WordPress. It is still in beta and in data collection mode. When it’s released, the collected information will be available from the wordpress.org API.

    As with every release there are hundreds of improvements and bug fixes. 410 tickets have been closed so far for the 2.9 milestone.

    One significant change is the new “trash” status for posts and comments. It works by changing the post_status or the comment_approved field to ‘trash’. If the post or the comment is restored from the trash that field is set back to it’s previous value. By default items in the trash are deleted after 30 days.

    If you use direct SQL queries you may need to exclude posts and comments that are currently in the trash. Simple example: https://core.trac.wordpress.org/changeset/12254

    Please ensure that your plugin(s) or theme(s) work as expected in WordPress 2.9-beta-2. If you have questions or comments please post them on the wp-hackers mailing list or in the Alpha/Beta forum on wordpress.org.

  • Andrew Ozz 8:51 pm on December 3, 2009 Permalink  

    Agenda for the December 3rd Dev Chat 

    • How do we handle security releases in the admin – Matt Martz
    • Create a post on the w.org dev feed that highlights what breaks to plugin devs – Denis de Bernardy (we’ve started the WordPress Developer News email announcements as discussed here couple of months ago that cover this)
    • Shall we remove Gears support now or in 3.0
    • Minimum intervals between first beta and final release and between first RC and final – demetris
  • Andrew Ozz 3:59 am on September 26, 2009 Permalink

    Image Editor 

    The “first run” of a simple image editor has been in WordPress 2.9-rare for about two weeks. It lets the user crop, flip and rotate an image. It also has an option to scale the original (largest) image and to restore the originally uploaded version. There is a multi-step undo and redo support. Changes can be applied to all image sizes or only the thumbnail. The initial code is by Stephan Reiter author of the Scissors plugin.

    Currently when saving an edited image all previous intermediate image sizes are kept and the meta data for them (filename, width, height) is moved to another postmeta field. This is necessary to avoid breaking any posts or pages where the image was inserted. The editing workflow (multi-undo, preview of each step) makes it unnecessary to edit an image more than once or twice, however if an image is edited 6-7 times the backup files would be 25-30.

    There are couple of ways to avoid keeping unnecessary images, we could either track when an image was used in a post or a page, or we could have “standard” names for the intermediate image sizes. Tracking image use can be somehow problematic considering all the different ways content can be published in WordPress.

    Renaming the resized images from [imagename]-150×100 to [imagename]-thumbnail, etc. seems the more viable option. This would also bring instant image updates in already published posts, however may also have some compatibility problems with plugins that expect the image size to be part of the filename.

    Trac ticket for the image editor, suggestions and patches welcome 🙂

    • Alex (Viper007Bond) 5:02 am on September 26, 2009 Permalink | Log in to Reply

      You could also just use a shortcode for the image tag, although that may not be as user friendly. Then again, if you move domains, URLs, etc. you wouldn’t have to edit the post.

      So instead of this:

      &lt;img src=&quot;http://blog.com/wp-content/uploads/imagename-thumbnail.jpg&quot; width=&quot;150&quot; height=&quot;100&quot; title=&quot;Cool image&quot; alt=&quot;ohai&quot; /&gt;

      You’d do this:

      [image id=&quot;123&quot; size=&quot;thumbnail&quot; title=&quot;Cool image&quot; alt=&quot;ohai&quot;]

      The URL, width, and height would all be dynamic and change if you changed the thumbnail size, etc. This is opposite of now where even if the filename didn’t contain the dimensions, you’re still left with hard coded width/height parameters in the image tag.

      • scribu 11:49 am on September 26, 2009 Permalink | Log in to Reply

        That would be nice. And it’s been requested several times in the past.

      • Xavier 4:47 pm on September 26, 2009 Permalink | Log in to Reply

        • Beau 9:30 pm on September 26, 2009 Permalink | Log in to Reply

          Since both uploads would have a unique id in the DB, it doesn’t matter if they have the same filename. The correct URL would be output dynamically, based on wherever it was stored (as referenced by the DB)

      • Andrew Ozz 12:57 am on September 28, 2009 Permalink | Log in to Reply

        Think this came up when we were doing the captions shortcodes a year ago and was rejected. Perhaps we can look at the pro & con again. Since all movies and other embeds will be handled by shortcodes it may make sense to extend that to include images too.

        However I see a possible problem with that. The img tag doesn’t need any processing on display but a shortcode would need quite a lot as it seems we will have to do get_post() for the attachment. Also our shortcode parsing code/API doesn’t seem optimized enough to handle large quantity of shortcodes.

      • Jonathan Dingman 9:22 pm on October 1, 2009 Permalink | Log in to Reply

        Would that imply dynamic resizing?

        ie, if someone changed the thumbnail size after already uploading the image, would it resize on the fly? (if specifying a thumbnail in the shortcode)

      • Denis de Bernardy 11:14 pm on October 3, 2009 Permalink | Log in to Reply

        Using a shortcode here would hammer the DB unless it’s properly implemented.

        And this “it hammers the database”, btw, is the reason I had opened:


        I use similar code in two plugins of mine, and since you can’t rely on an attachment from being tied to a single post, I check for a post meta to make sure there are attachments (and which ones) before tossing a query.

      • Alex (Viper007Bond) 6:56 am on October 4, 2009 Permalink | Log in to Reply

        We also have to not forget about those who use TinyMCE and expect to see the image as is. A shortcode would be there as text.

        Perhaps a TinyMCE plugin could AJAX fetch the image (based on ID) and replace the shortcode with the image during editing, then put it back to the shortcode on save. That way it’d still stay a WYSIWYG.

        • aarondcampbell 9:53 pm on October 4, 2009 Permalink | Log in to Reply

          That’s a good point. It’s easy to forget about those using WYSIWYG

    • Barış Ünver 6:33 am on September 26, 2009 Permalink | Log in to Reply

      I’m concerned about the fact that WordPress is getting fatter and fatter each version. Is it really necessary? Couldn’t it be done with a plugin or something?

      Or at least, are we gonna be able to se a lighter (official) version of WordPress? LitePress v2.9.0 maybe?

    • Andrew Ozz 1:37 am on September 28, 2009 Permalink | Log in to Reply

      Another solution for the multiple image backup files would be to let the user decide. We can include a checkbox whether to delete the previously edited image (together with all sub-sizes). Since the suffix that is appended to the image filename contains a timestamp, we could do something like “This image was last edited 1 hour ago. If it wasn’t used in a Post since then you can remove the backup files by selecting this checkbox”.

      On the other hand even the cheapest hosting accounts seem to come with a lot of storage so deleting backups would be unnecessary. Also a plugin can add a simple GUI to search the db and return a list of unused backup images that can be deleted. Not sure if something like this would be good for core.

    • Otto 6:07 pm on September 28, 2009 Permalink | Log in to Reply

      I think the key to this problem is the following: “This is necessary to avoid breaking any posts or pages where the image was inserted.”

      Why avoid breaking those posts/pages? If somebody edits an image, then change the image itself. That’s what they will probably expect to happen.

      Having to have them go and reinsert the changed image into the page/post is confusing and unnecessary. We don’t need to save the original. The user uploaded the image, presumably they have the original. An in-place editor should simply overwrite the existing files with the new ones, not try to preserve them.

      • Andrew Ozz 12:30 am on October 1, 2009 Permalink | Log in to Reply

        True, users that know what they’re doing may expect to break old posts when editing an image. However the majority will most likely complain that “the image editor breaks all old posts!”.

        Also we cannot just replace the originally used image with the edited one as images are inserted with “width” and “height” attribs that in most cases will distort the edited image (as Viper007Bond pointed above).

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar