 | siobhyb on JSON REST API |
| siobhyb on OPW Introduction – Hello… |
 | Dan on JSON REST API |
 | tuyendart on JSON REST API |
| Tips Tuesday – Relea… on Summer of Code Revisions |
As noted in The Road to 3.6 Beta 1, we’ve got quite a bit going on for post formats. Many of the tickets are in need of testing (including unit tests) and then a commit. As always, there are a few different fronts: UI/administration, data, and parsing. Here’s where we are with each, and what needs to get done. There’s a large variety of tasks here, and we are seeking contributors to help 
Improved user logout notification ( #23295 ) is now in core, and its UI has been tweaked to directly show the login box, rather than prompting first:
There’s been discussion as to whether it’s better not to block the user’s access to the editor/current page when we detect that you no longer have a login token, since it could stop a user while they’re in the middle of a sentence. Any opinions either way? Feel free to comment either here or on #23295.
A simple way to test the above is by removing your login cookie while working in WordPress (Firebug works well).
On local autosaves, there was a decision to pivot from the previous UX posted here, and instead integrate with the new revisions model. This code is still being worked on.
In the land of post locks, @azaozz posted a patch on #23697, that shows a dialog either when you visit a locked post, or when your post becomes locked. If you are visiting an already locked post, you have the option to break the lock. This is still in need of UX/UI love, but looks like this currently:
Finally, a patch on #23665 allows for one autosave per user per post, rather than per post, to let us keep an autosave from before you lost a lock. Testing on this, and the rest of the above welcome!
I think the session expired modal should darken the rest of the page. It kind of blends in as-is.
Agreed. I think that was initially left over from the “let’s let the user continue to work” mentality. If we’re going with “Your only path is to log back in,” then making it darken the rest of the page is appropriate.
I agree with @MarkJaquith. I took a quick stab at mocking it up:
Was testing something similar too and agree it looks better. The only concern is that it will frighten the user when it shows.
Most commonly this will show on the Add / Edit Post screen (as the users spend most time there). Imagine typing a new post, uploading images, etc. and suddenly the screen with your work disappears and is replaced by the login screen telling you to log in again. I bet two “scary” thoughts would go through your head: “What happened to my post?” and “This asks for my password, is it legit?”. Additionally the screen change will most likely cut you in the middle of a sentence and can literally startle you.
In the original patch this was a two steps process: a non-modal (position fixed) warning shows first telling the user that the session has expired and asking to log in again. As the rest of the screen is visible this is not that scary (you can still see your work) and won’t startle you as most of the screen doesn’t change. Then clicking a link or a button in the warning opens the actual login screen in a modal.
Perhaps this is a better solution. Yes, one more click, but better user experience.
I think we can likely find a way to lessen the fear by getting the copy right. You could also bump the darker outer margin up (maybe double the margin), and perhaps lighten the opacity a tad, so that the user still can see some of the screen behind.
I prefer the one step (taking them straight to the login form), vs. showing an intermediary step (which looks more suspect than the log in form with the logo above it, to be quite honest). If they’ve saved their login details, they only have to click once (on the “Log in” button), and they are right back to their writing.
+1 — Translucency allowing the user to see that their content is still back there, undisturbed, perfectly conveys the notion that “your session has expired, we need to re-authenticate you so that you can follow working as if nothing had happened”:
IMHO, you nailed it.
This is a rather late update, and will serve for the last two; apologies!
Last week, we talked about the locks that went in, and @markjaquith suggested that we replace the “lock” with a Gravatar, which I like quite a bit. Will experiment with that to see if it can work.
Today we chatted about the most recent update to #23220 posted by @azaozz, which integrates the work done by @asannad (AmitSannad on IRC), and adds a UI for selecting which you’d like to restore: 
In addition, if it’s found that you have an autosave that has failed, and have a newer version locally, you’re warned (either on the Posts list or Post itself), and linked to the UI that allows you to restore the content (post content and title only) and save at will:
It was brought up during the chat by @nacin that the UI included in the patch might be more than we need, and that we should decide what is best for the user regarding restores, and perform it for them. We continue to chat about this, and opinions are welcome!
Lastly, there is a patch from @mintindeed on #23295 currently waiting for integration! That patch, and the one on #23220 could use some testing — let us know if you run into problems on trac.
We’ll be meeting again this Friday at 2100 UTC (1pm PST).
Oops I missed today’s meeting.
I am working on some revisions to my patch based on feedback from last week’s meeting, unfortunately work is killing me this week so it will probably be the coming weekend (Feb 16–17) before I get a revised patch up there.
A quick update on status!
Earlier this week, the initial run at the Heartbeat API went in. @azaozz is continuing to work on it, and flesh out the API further ( #23216 ).
Tonight, the initial post lock view for the post listing was committed [23355] along with a temporary icon:
I took a look over an older version of the NYT plugin kindly contributed on #18515.
For discussion, I’m including a few examples of the UI/UX from the workflow included in it below.
We don’t necessarily think everything here is a good idea for core (for instance, the “get me out” buttons wouldn’t be necessary), and will likely go a different route for UI, but hoping to get a bit of discussion going regarding the UI/UX flow for the project.
Lock table:
Lock table user mouseover:
Popup for lock within Post Editor:
The first icon goes better with the new icon sets that’ve been worked on. Don’t forget to loop back to that group 
What user levels can break locks? Is it hierarchical so Admins can break anyone’s locks, but Editors can break admins and so on down the line?
The alert boxes greying out the screen behind is good, that reinforces ‘Hey! Someone’s in here!’ You could use that extra space to have something like …
Warning: POSTTITLE is locked
Other Person is currently editing this post.
You can view the post as read only, exit out, or unlock the post and take over. If you chose to break the lock, their edits will be lost(?).
Why not open the edit screen as read-only directly? Greyed out with a warning on the top of the page which contains the “request” and “force” buttons. Content refreshes every 15 seconds and you directly see what the other is working on. Less buttons, less clutter.
Read-only on edit is what we’d initially chatted about, so I’m glad to see you agree! I really like the idea of having the warning within something similar to the current warnings, only with “request” buttons there. Do you think it’s important to be able to force immediately, or only allow that after you’ve requested, and don’t immediately get feedback?
I think… people don’t RTFM enough. A splash is annoying, but less likely to miss (never underestimate the ability of people to click on something without reading).
Grey everything out and set the input fields to read only. Then refresh them all 15 seconds with auto-save changes from the current editor.
@Mike Schroder: I think a button to force-get the right for editing would be necessary for people with a higher role. Still, the user currently editing would need to get a warning and a countdown for deciding to save or discard his work.
And is it already planned to add a “x people are watching you editing this post” notification?
Yes, we can use a modal to block access to the Edit Post screen when opening a locked post and show a “preview” of the latest content entered by the other user. In that modal we won’t need the “Read Only” button from the above screenshot and the “Get Me Out” would be “Return to [previous page]” or “Go to All Posts”.
The “Unlock” could be “Request to edit” or “Request the lock” which will pop up a notification on the other user’s screen letting them finish what they are doing and save or perhaps refuse to give up the lock.
Instead of a modal, this can also be a whole different screen. Then after the lock is transferred, the user will be able to load the post for editing. This way we will be loading everything fresh from the server.
I know this maybe off-topic, but the whole idea of the hearbeat API and even perhaps showing updates from a locked post to an editor who is about to acquire a lock makes me think about perhaps making it a full collaborative editor? Why not go that far? It seems we’re already getting close. It’s a matter of sending/receiving diffs on the long-polling method which was discussed earlier.
We had our scheduled meeting today in IRC to continue planning the feature for this cycle.
@azaozz noted that he’s continuing work on the Heartbeat API #23216, on schedule for initial commit before next week.
I am continuing work on an initial pass for the post/page tables to display locks, and properly display edit/bulk edit links when locked. Should have an initial pass ready for view on Monday.
@mintindeed offered to help port his plugin to core for improved login expiration warnings, which is great! He’s created #23295 to track the efforts.
@asannad (AmitSannad on IRC) offered to help with localstorage Autosaves, which is being tracked on #23220. Initially, we’ll use a simple schema for storage, but will probably need something more complex later on to avoid collisions where multiple databases are used within the same domain.
As initial guidance for improved workflow for locks, we’re looking over the plugin mentioned in #18515. @nacin is checking with the authors to see if there’s a new version we can take a look at.
Our next meeting is on Tuesday, January 29th at 2100 UTC (1pm PST).
Just confirming that I’ve sent an email.
Today we had our first scheduled meeting.
Consensus was, for a first pass:
As far as development tasks go, @azaozz is planning on finishing a first run at the “Heartbeat” API to be committed before the end of the week. I’ll begin working on the list table changes for post listings. We’re currently looking for volunteers to aid, as there’s plenty of room for help! Additional tasks will include the UI for handling post lock requests and auto-save to local storage.
We’ll certainly chat more about this tomorrow in dev chat, and are planning another meeting this Friday (2013–01–25), at 21:00 UTC (the same time as dev chat), unless this doesn’t work for many of you looking to help. Please post here, or come to the chats if you’re interested in helping with this project, and we’ll get in touch with you for further details!
fantastic. i’m on pins waiting for this implementation. can’t wait!
The idea for implementing post locking is for a person to manually click a Request Lock button in the edit post screen? Would that show up on all installs or only installs that are multi-author? Why not automatically lock a post when editing it so the workflow is streamlined?
Good questions. The Request/Take over a lock button will only show when the same post is being edited by another user. Under normal circumstances posts would never be locked on installs with only one user. However if the user opens the same post on two different devices (computers) or in two different browsers, the first instance should lock the second. That should also happen if several people use the same user account.
We already monitor when a post is being edited and show a warning. The purpose of the enhancements is to actually prevent saving a post from two different places simultaneously.
Thanks for the clarification. Sounds great.
Will this be implemented in the mobile apps? I’m wondering what would happen if someone tried editing a locked post from a smartphone or tablet, and would those devices be able to lock and/or take over a locked post?
That’s the idea — you’d get the lock automatically if the post isn’t locked by anyone. Then, if it’s already locked, you have the option to request the lock from the author that holds it. The feature would still exist on single-author installs, but you wouldn’t notice it, because you’d be the only one able to hold locks.
[edit] Previous comments weren’t showing when I typed this. @azaozz‘s comments above explain further [/edit]
Unless I’m misunderstanding, this approach seems like it could result in posts becoming permanently locked.
1. Open post for editing
2. Walk away
3. ???
4. Profit
To resolve this issue, we’ve talked about including a concept of activity via keystrokes and maybe mouse movement to maintain the lock assignment (otherwise, a user would lose the lock after X amount of inactivity).
We can also monitor user activity comparing autosaves to the server. If there are no changes for x minutes, user is inactive. Maybe we can set another flag for “user-active” in the post lock and toggle it based on autosaves.
As Mark pointed out earlier, this task includes several different components:
“WP Heartbeat” API, #23216. This will do polling or long-polling so the server is able to send data and notifications to the browser. The primary use will be for setting, monitoring or taking over a post lock. Additionally it will be used to send autosave data to the server. It looks like we won’t need long-polling for now as post locks are not that time sensitive. A “standard” polling every 15 seconds would be sufficient.
Post locking. How exactly to lock a post and how a user can take over the lock? Best would be to prevent user B from being able to edit the post while user A is still writing or editing. Some ideas discussed at the IRC meetup yesterday are to overlay a transparent div over the editor and/or set the form fields to read-only. There will be a button for user B to take over the lock, clicking it will prompt user A to save the post and close the browser tab. While user B is waiting to take over, we could show a non-editable “preview” of the content (even inside the editor) updated with every “heartbeat”.
In addition we would show whether a post is being edited on the Posts screen (list table) , perhaps with the same type of button to request taking over. Other ideas welcome.
Autosave to the browser’s local storage, #23220. Keep several revisions of the content on the user’s hard drive, saving every 10 seconds and “flushing” to the server every 2 minutes (same as currently). After saving to the server (including saving a draft or publishing), empty the local storage and start again. So at the end of creating or editing a post, the local storage will be empty.
This will require “plugging into” the revisions API for restoring revisions from the local storage and some UI for letting the user recover the last revision from local storage when it exists.
Log-in expiration warnings. Update the current functionality to use the new heartbeat API and improve the UX and UI. We can detect cookies expiration earlier and show a warning that would open an iframe so the user can log in again. After that interim log-in, we will need to update all nonces.
The first feature team meeting in IRC will be next Tuesday, 22 January at 1pm PST / 21:00 UTC. Please join us if you’re interested in participating in the development of any of the above components.
Here’s some previous work on the expiration warnings: http://wordpress.org/extend/plugins/pmc-post-savior/
Re Post Locking: can we keep in mind the future possibility of real-time collaborative editing or is that just way to far out of scope to even plan for?
+1 to the 2nd user to enter the editor to be displayed the post in a “locked” view with a button to “request control” or “take control”
real-time collaborative editing sounds great for a future release.
This is exciting stuff. Will the autosave have ways to contribute custom content that might be stored in custom metabox fields, attachments, and other relevant items ? Maybe that already exists but if so I wasn’t aware of it.
By the way, for anyone looking for related tickets, I’m trying to keep them tagged under autosave-redo: http://core.trac.wordpress.org/query?keywords=~autosave-redo
Looking at open tickets in the Autosave component should be sufficient, optionally limiting that to 3.6-milestoned tickets (which shows some need a milestone).
I want, as a major 3.6 bullet point, that we should never lose posts due to expired cookies, loss of connection, inadvertent navigation (even if AYS’d), plugin or core errors on save, browser crashes, OS crashes, cats walking on keyboards, children drooling in keyboards, etc. I want people to trust WordPress with their posts. They should never fear that something they’ve spent time creating or editing should go away due to their mistake or ours or that of a third party. Mistakes and errors should be recoverable. I can’t stress enough how important it is that people believe this and have good reason to believe it. If a post gets lost, there is a catastrophic loss of trust, that could take years to be regained (if indeed it ever is). This is people’s time and their creative output we’re talking about. If we’re not valuing those things above all else, then our priorities are seriously out of order. This is an all-hands-on-deck item for 3.6. Even if you’re not actively working on the code or the copy or the UI or the UX I want you to be thinking about ways in which WordPress could better treat your creative output as the valuable artifact it is.
Things this will likely involve:
@aaroncampbell and I have chosen @azaozz to lead this, as it will probably be very JavaScript-heavy. There are a lot of moving parts here, so please leave a comment if you’re interested in this important, heroic, virtuous endeavor.
+1!
+1 – May I suggest that versioning and autosaving of metadata be included in this push. I’ve seen several people become reliant on the revisions and auto-save of the content (yay, they trust it!) and then be disappointed to discover their excerpt or content in a metabox isn’t given the same treatment.
There’s at least one ticket that touches on that http://core.trac.wordpress.org/ticket/20299
But yeah, we need to start thinking about the fact that as more people use WP as a CMS, a lot of their important data resides outside of post_content.
Absolutely this. We make heavy use of post meta in sites we build for people, and storing revisions would be a huge plus. Does anyone know of additional tickets that address this? (The one Mark linked to is specifically focused on the fact that previewing changes to a post updates meta (silently), which isn’t expected behavior).
Thanks Helen. Might I suggest that it would be natural for #18179 to include an argument such that when a metabox is registered, the keys in that box are then registered to have revisions tracked.
Huge +1.
+1, I’m very interested in helping work on these features. I’ve worked with the authors on the site I manage to find workarounds for a number of related problems and have several ideas I’d like to test out:
i’m interested in helping if i can
omg. yes.
And on top of that… While you guys are at it, make the dashboard, the whole of it, faster. Better loading, faster rendering (?) Whatever. Often on sites that have a bunch of plugins active it get’s really sluggish.
This is largely dependent on what they plugins you’re talking about do on the dashboard. Sounds like they’re likely doing something wrong if they’re slowing down the dashboard that much.
Or nuke it altogether. I don’t have numbers but I’m guessing the majority of people spend 1% of their time in the Dashboard. I find it altogether useless, although I’m sure some would disagree with me.
When I login to WP to produce content, the first thing I do is click on Add New in the posts menu. That’s a hover and a click more than I need to get into content production.
I have been doing a decent amount of work around offline storage recently and would love to help contribute on the JS side of things.
Excellent.
Thanks, Mark. This is a great goal, and worthy of the urgency you’ve expressed! Since you mentioned post revisions, I’d like to recommend that we think about how to better compare post/page/CPT revisions within the rich text editor. As it is currently implemented, non-technical users have difficulty comparing large amounts of plain-text and raw HTML, and often give up immediately when using the compare feature. Developers are accustomed to the unified diff format, but we’re the only ones.
Could we take inspiration from the review/editing/comparison tools used in other popular copy-editing apps (i.e., MS Word) that would make a copywriter feel more at home when comparing content revisions?
I’d like to lend a hand with this, I can provide user insight (our dev team has been fielding issues regarding this topic for a few years from a large staff of writers) as well as do PHP and JS coding for it.
Definitely loop Gabriel in on this, I’ve been using his ‘PMC Post Savior’ plugin recently and it’s been a huge help in preventing lost posts: https://github.com/Penske-Media-Corp/pmc-post-savior.
The best part about Post Savior is the UX rethink. Instead of a load of JS and localStorage it allows re-login over the top of the post interface. Really simplified the JS/localStorage fixes suggested on Daniel’s blog: http://danielbachhuber.com/2012/05/01/notify-when-logged-out/
…also worth checking out the discussion on that post too. Having the JS/storage-type fixes might be needed for full protection on mobile browsers.
I’d like to help with this during this cycle too.
Since I’m time-limited to being effective on only 1-2 tickets per cycle, I be happy to help with tests and testing if time there would be valuable.
For Wednesday, let’s plan on a 3.5.1 ticket triage meeting at 19:00 UTC (2 p.m. Eastern). Please be around if you can (#wordpress-dev of course), especially if you have something in progress for 3.5.1, so we can hammer things out and start thinking about timing.
The dev chat is normally two hours later, at 2100 UTC. I won’t be available, and will leave that to @markjaquith and co. I expect it will be a light meeting again. 3.5.1 timing should be discussed, which should be easier with the triage session happening earlier.
I’m currently feeling January 2 for a 3.5.1, which gives us a few weeks to fix everything in the pipeline. We could offer a hotfix now for #22985 and #22944, which both screw with data.
Specific 3.5.1 tickets to discuss:
Additional notes on remaining tickets:
I don’t suspect #22899 is the source of the mod_pagespeed issues, since encoding the brackets doesn’t solve the problem. We’re reaching out to the mod_pagespeed guys on this, and adding a temporary rule to avoid mod_pagespeed optimizing wp-admin’s JavaScript (which it arguably shouldn’t be doing anyway).
#23041 needs review for 3.5.1 milestone.
And as alluded to in the previous comment, is there anything we can offer a hotfix for? This should be based on both severity and impact. Is forcing out a fix for load-scripts.php (that involves either encoding [] or chunking <script> tags) enough to fix most JS issues? If not, is there anything else we can do to avoid a lot of JS conflict/error issues people are having? Is there a common pattern in the support forums that suggest there is something we can target? etc.
Suggest items for today’s developer chat.
September 5 is the “soft freeze”. I pictured this as a status check and a time for evaluation. At this point, we mercilessly cut things and quickly reassign contributors to things that need more attention.
That means a lot of things need to start landing this week.
i cant auto update to the latest nightly build
Seems like there are database tickets all over the place which deal a number of different things:
They don’t all fall under “database” in workflow and a lot haven’t been tagged 3.5. It would be great to organize an overall view of these issues, whether here or on Trac. Not to the extent of make.wordpress.org/db or anything, but perhaps a master list of: things that are very related to database but are currently in components Database / Taxonomy / Query.
I can help with this. It would good to see what is there, what’s gonna make 3.5, and what is punted and why.
@wonderboymusic, meet @pento. I think this will be the start of a great friendship. Let me know, I’m happy to help you both in this.
I also volunteered to look at some of the database stuff and have – a little bit. Most of it looks pretty good. I am a bit weary of adding indices for a single use case – http://core.trac.wordpress.org/ticket/15499. I think we should be weary of doing this as it probably means there is something else wrong (maybe the query should be different) or an existing index should be changed instead of a new one being added.
I just looked at all of the “bugs” in the Nacin filter – a lot of weird history in there! Here is a list of tickets that look to *me* like low-hanging fruit, bite-size, have patches (not all mine, many others), etc. Most of these have been hanging around for a while, and if they are NOT good candidates for inclusion: should maybe by closed, or the conversation restarted – but like I said, all have fixes / patches:
Meta and Tax Query without nested arrays
http://core.trac.wordpress.org/ticket/17235
Duplicate $$$ terms
http://core.trac.wordpress.org/ticket/17689
Allow a single taxonomy to be passed to get_terms() as an array.
http://core.trac.wordpress.org/ticket/17955
Slow SQL in get_adjacent_post()
http://core.trac.wordpress.org/ticket/18120
Searching with explicit post types unsets page post type
http://core.trac.wordpress.org/ticket/18513
Die fast in get_posts if in_search_post_types returns nothing
http://core.trac.wordpress.org/ticket/19198
Unneccessary term cache query for pages (set $post_type to page before update_post_caches)
http://core.trac.wordpress.org/ticket/20177
wp_list_pages fails with meta_value=0 criteria
http://core.trac.wordpress.org/ticket/20376
is_tax() with term parameter returns true for any taxonomy with that term
http://core.trac.wordpress.org/ticket/20590
Empty tax_query returns all posts
http://core.trac.wordpress.org/ticket/20604
Duplicate term insertion allowed after insertion with case differences
http://core.trac.wordpress.org/ticket/20850
error_log() not called in wp-db.php when error_log setting is empty
http://core.trac.wordpress.org/ticket/21103
$wp_query->found_posts is set to 0 with posts_per_page=-1
http://core.trac.wordpress.org/ticket/17066
Found posts not filled correctly
http://core.trac.wordpress.org/ticket/21147
get_all_category_ids() only used by a deprecated function
http://core.trac.wordpress.org/ticket/21200
get_cat_ID(): category “General” does not exist anymore by default
http://core.trac.wordpress.org/ticket/21201
reporting typo in dbDelta
http://core.trac.wordpress.org/ticket/21272
wp_set_post_categories fails if input array index starts with other than 0
http://core.trac.wordpress.org/ticket/5096
wp_get_object_terms should return arrays of integers for IDs and tt_IDs
http://core.trac.wordpress.org/ticket/17646
Garbage collect transients
http://core.trac.wordpress.org/ticket/20316
I would like to discuss: http://core.trac.wordpress.org/ticket/16416. Privacy vs. General vs. Reading Settings, “Site Visibility” versus “Search Engine Visibility,” and checkbox versus radios.
@bpetty wrote up a great page on triaging tickets. It would be great if others can contribute to it as well. http://make.wordpress.org/core/handbook/bug-gardening/
I’d like to discuss whether http://core.trac.wordpress.org/ticket/6821 is far enough along not to get cut.
also, I wrote a unit test for this: https://core.trac.wordpress.org/ticket/5809 – this would be killer to get in
Whether or not the new media UI/workflow is on course and/or whether any of the patches are ready to go into trunk
Improving the search query (also related to the DB stuff above), tickets http://core.trac.wordpress.org/ticket/7394 and http://core.trac.wordpress.org/ticket/21688.
This started as a quick “weekend” project to make the search return post titles first. Was thinking to add another query arg to only search titles, but that’s too limiting. The two patches above make searching for posts much much better without changing anything too drastically.
@azaozz – I looked into this a bit on some large WP sites and I think we should try it out on WP.com first so we can see the actual performance impact across millions of sites. It also means it won’t get combined with a bunch of other changes so we can measure the impact more precisely. It’s a non-destructive change and can always be reverted.
I’d love to see #17807 discussed. It’s been hanging around since 3.3 and I’ve tested it heavily. The refresh patch didn’t change anything appreciably, it was mostly coding-standards fixes.
It would also be great to see Viper007Bond’s date query improvements discussed: #18694.
jltallon, 
lessbloat, 
Luke Gedeon 3:32 pm on March 15, 2013 Permalink | Log in to Reply
“Add New Post: Status” in the refreshed layout wireframes shows permalink above status field (Hey User, what’s up?) and has no title. As a user, having the status field above permalink feels more natural.
As a dev, I wonder if we could use the Title field to capture the status instead of a custom field. This would allow normal processing to generate the permalink and put the order of fields into something closer to what a user might expect.
When generating output for a status it “might” be preferable to hide the title even in themes that don’t recognize post formats. If that is case, core could return an empty title and the status stored in title as content. My preference would be to receive the status as a title anyway, since that would look best in most themes I have looked at.
Helen Hou-Sandi 7:13 pm on March 18, 2013 Permalink | Log in to Reply
Status is not a custom field – it’s post_content. I don’t think we’re going to be able to get so adventurous with the status format edit screen layout – it’s quite likely that it’s going to just look the same as aside – title optional (toggle or otherwise), regular editor area. I also don’t think core should just turn titles off in a theme – that’s completely up to the theme to decide. A theme may very well use the_content in a way that looks like a title – 100% presentation layer, not data.
Dravel 5:27 pm on March 15, 2013 Permalink | Log in to Reply
As a regular “John Doe” user of WordPress I must say that the plan of ditching the tabs in favor for the drop down thingy from @lessbloat is a major disappointment. The tabs were a new fresh style (needed one to) to a stale design part of post area itself.
Reverting to a style that best described as 1995-ish when we are in fact roaming in the year 2013 is a huge step back, not to speak of the user unfriendliness the current iteration presents (http://make.wordpress.org/core/2013/02/22/post-formats-ui-update-221/#comment-8182), that little blob before the “Enter title here” does in no way even hint that there’s option’s lurking there. As a blogger I want it easy and straight forward, not guessing around before I can actually start to write my things.
The tabs were ok and had a fresh thing to it, shoot even a vertical row of the icon’s made by @melchoyce with a sub title “Post Format” as a <h2> heading right under the “Enter title here” is way better than a obscure drop down thing, especially from a user friendly point of view.
Just 0.2 cent from a regular John Doe user
Helen Hou-Sandi 7:18 pm on March 18, 2013 Permalink | Log in to Reply
There are a lot of problems with the tabs interaction-wise. They are not adaptive to screen widths, especially smaller ones, incorrectly represent selecting a format as a primary action when in reality it is one that is performed once and then left alone, and they cause confusion among users, both “regular” and ones we tend to think of as knowing better (like the very people writing patches). Some users interpret the tabs as needing to fill out all of them rather than making a generally-one-time choice that sticks, and yet others saw ones like “Audio” and “Video” as being points for inserting media into their content. We have a lot of exploration to do, but tabs are definitely not it. Again, I regret having put them in even as temporary UI – the distraction caused has been a bit time-consuming to respond to.
WraithKenny 8:31 pm on March 18, 2013 Permalink | Log in to Reply
have you tried using the “button-group” styles? I make a quick plugin for showing what it’d look like: https://gist.github.com/WraithKenny/5190524
Helen Hou-Sandi 10:03 pm on March 19, 2013 Permalink | Log in to Reply
I don’t think buttons are the right interaction, either. The thing I want the most is for the selection/switching mechanism to get out of the way once a choice has been made. Interaction is what’s most important here; it’s not merely a matter of styling.
jltallon 1:00 pm on March 20, 2013 Permalink | Log in to Reply
From another “John Doe” user (+developer +project manager):
@lessbloat‘s proposal at the URL below is right on: discoverable, intuitive, unintrusive, practical… good.
Though I’m a bit wary of content parsing, I trust you to get it right, and the “teeny” mode will be of much help in guiding the users along the right way (input the “correct” content). Less meta is good for performance, too.
0.02€ from me
Hugh 9:25 pm on March 15, 2013 Permalink | Log in to Reply
I’m a lurker, but can someone point me to a post or discussion on the history of post formats? I am curious to know why the post formats for audio and video are not separate content types. – I’m sure there is some good thought behind this but being newish I’d just like to read why it is the way it is.
Helen Hou-Sandi 7:22 pm on March 18, 2013 Permalink | Log in to Reply
I suppose the Codex has some information about what post formats are: http://codex.wordpress.org/Post_Formats, notably “A Post Format is a piece of meta information that can be used by a theme to customize its presentation of a post.”. Separate content types (post types) would not show up in a blog archive by default and are not posts, whereas these are supposed to be posts that just happen to contain audio or video (or quote, image, gallery, chat transcript, or link). Think of post formats as a way for users to structure/think about the content of their blog posts and as a way for theme devs to be able to customize the presentation layer of a given format.
WraithKenny 8:38 pm on March 18, 2013 Permalink | Log in to Reply
“…what it means to re-initialize TinyMCE…” Is there a ticket or comment on which scenario would require TinyMCE to be reset?
Helen Hou-Sandi 10:02 pm on March 19, 2013 Permalink | Log in to Reply
Teeny mode may be more appropriate for some post formats, e.g. quote.
Scott Taylor 10:22 pm on March 18, 2013 Permalink | Log in to Reply
I am on a plane home from my Mexication – I am going to refresh my patches tonight, based on the fact that #23282 finally landed (editors note: woo hoo!). The patch on #23282 had some new functions (`has_shortcode()`, `shortcode_exists()`, `get_tag_regex()`, et al) that were present in ~5 different patches. Will also streamline any dupe’d code elsewhere among the patches that haven’t been committed. That being said , #23673 should be the next one to go in.