Call for Testing: WordPress for Android 7.6

WordPress for Android version 7.6-rc-1 has been released in the Google Play Store. You can join the beta from the Google Play Store on your device (under “Become a beta tester”), and comment here or join the Google Plus beta community for more discussion with other testers. (Note: If you see a message that the beta testing program is full, you’ll need to wait for space to open up before you can join the beta. Thanks for your interest!)

What to Test:

New: Unified Media Browser Picker

Your site’s media library (the Media section) has an improved UI (see here), and now it’s been unified as per the work done here. Check it out and let us know if you find any problems!

New on Aztec

This new build uses the Aztec editor latest version (what’s Aztec?) by default, which now has the following improvements:

  • <pre> tag with with white-space formatting support
  • Changing heading type for multiple headings bug fix
  • Disappearing context menu during image upload fix
  • Paragraphs disappearing while deleting fix
  • Toolbar buttons selected state style change
  • Now you can add images from the new WordPress media library
  • Fixed a bug when it wasn’t possible to save an empty draft

More details on the work in Aztec included in this version of WordPress for Android can be found here.

Bugs & Feedback

Did you find a bug or come up with a feature request while testing? Did you try the additional flow testing? You can discuss it here, report it using the “Enter feedback about the app” form in the Google Play Store, or head straight to the Android Github repository and open a new issue.

Thank you for testing!

#android, #beta, #needs-testing, #wpandroid

Call for Testing: WordPress for iOS 7.8

WordPress for iOS version 7.8 beta is available for testing on TestFlight. Not part of the beta program yet? Please sign up for our TestFlight program to request to join as a beta tester.

What to Test

1. Media Library

We’ve added a top-level Media Library section to WordPress for iOS for each site you manage, bringing it in line with WordPress for Android. Previously, you could only access the Media Library for a site when you inserted media in the editor.

Using the Media Library, you can view your media, search, edit metadata, delete items, and upload new items. Please take it for a spin and let us know what you think!

To access a site’s Media Library, simply tap the Media row on its details screen:

Several Bug Fixes & Improvements

There were a lot of other improvements made in this release that aren’t being called out in this post. You can view the entire list here.

Bugs & Feedback

Did you find a bug or come up with a feature request while testing? You can discuss it here, ping one of us in the #mobile Slack room, report it using the TestFlight feedback link, or head straight to the iOS GitHub repository and open a new issue.

Thanks for testing!

#beta, #ios, #needs-testing, #wpios

X-posting Proposal: WordPress Community Conduct Project

Please read + comment on the original post.

Proposal: WordPress Community Conduct Project

Aztec Native Editors Technical Overview



Aztec is a new native rich-text & HTML editor with focus on performance, stability and flexibility. It’s available for both iOS and Android. The primary motivation behind the project was to provide a great editing experience for the mobile WordPress app but it’s being developed as a standalone open-source library, so other developers can use it and build something on top of it.

This post gets more into the technical features and implementations of each of the two flavors of Aztec. The architectures are both complex and this overview should help start the process of understanding how all the pieces work together.

Want to get more involved with testing Aztec? Feel like using Aztec in your own app and contributing back? Read more about Aztec and the release here.

User Features

There are a set of core features that Aztec is aiming to support with its initial release. Both versions of Aztec (iOS & Android) have used very different native implementations/libraries/techniques but the goal is to provide a similar user experience in your app.

Follow is a list of those features – we’ve noted features to be available (TBA) soon if they’re not ready yet.

  • Rich-text & raw HTML editing support with built-in synchronization
  • HTML formatting & color highlighting
  • Paragraph Indentation and alignment. (Android-TBA, iOS-TBA)
  • Ordered and Unordered Lists
  • Nested lists (iOS-TBA)
  • Blockquotes
  • Image support
  • Video support (Android-TBA)
  • Image alignment and text-wrapping (Android-TBA, iOS-TBA)
  • Pre tags. (iOS: renders but doesnt allow adding)
  • Font Styles: bold, italic, strikethrough, underline
  • Font Coloring (Android-TBA)
  • Header styles
  • Line breaks and paragraph breaks
  • Unknown HTML tag editing (iOS: renders but doesn’t allow editing the contents in Visual Mode)
  • Horizontal rule (HR)
  • Code blocks (iOS-TBA)
  • Beautiful HTML source editor (iOS: still not styled, or “beautiful”)
  • Emoji support
  • Spell-check
  • Voice dictation
  • Edit history (undo/redo) (iOS-TBA)
  • RTL language support (Android-TBA, iOS-TBA)

Technical Deep-Dive



  • Aztec.TextView [ GitHub ]
    • Interacts with HTML using the new setHTML() and getHTML() methods.
    • Allows the client App to set the HTML contents, and not have to worry about the parsing.
    • Inherits from UITextView so:
      • It supports RTL text orientation, unicode (and emojis!), dictation.
      • Editing can be switched ON and OFF
      • Can be placed anywhere in your app.
  • Aztec.FormatBar [ GitHub ]
    • Native UI component inheriting from UIView
    • Aesthetically customizable through Aztec.FormatBarItem
    • Logically customizable through Aztec.FormatBarDelegate
  • Aztec.TextViewAttachmentImageProvider [ GitHub ]
    • Allows rendering custom NSTextAttachment subclasses.
    • Used in the example App for custom HTML-comment rendering.
  • Aztec.TextViewMediaDelegate [ GitHub ]
    • Aztec relies on your App’s own networking stack.
    • Does not have network library dependencies of its own.


  • Written entirely in Swift 3.
  • Currently targeted at iOS 9+ but will most likely be 10+ when fully shipped.
  • Available through both CocoaPods and Carthage.
  • Currently includes 326 unit tests and 16 UI tests.

Third-Party Dependencies

Aztec iOS was developed to try to keep the dependencies count as low as possible. There are currently only two dependencies:

Challenges We’ve Faced

Synchronization of NSAttributedString and our DOM representation

One of the main goals behind Aztec was to provide a visual HTML editor that would maintain its HTML source intact as much as possible.

The reason is that HTML tends to be very sensible to changes when combined with custom CSS or even with javascript.  We recognized that it would be important to not lose any information between the initial input, and the final output after visually-editing it.

We wanted a file with a few localized edits to look almost the same as the original file.

Part of the problem with not losing information was that NSAttributedString uses a one-dimensional approach to styling, whereas the DOM tree uses a bidimensional approach.  In straight HTML there’s a parent-child relationship between tags (and text-styles) that simply does not exist in NSAttributedString.

Our experimental approach was to basically maintain an NSAttributedString as a sort quick visual cache to show on screen, and to map the edit operations to a parallel DOM structure.

Needless to say, this is a very difficult approach to maintain because there’s a big risk of de-synchronization between the cache and the DOM structure.

We’ve done a lot of work to ensure this is not a problem, and to some degree we’ve been successful, but we’re still suffering a bit from maintainability issues due to the complexity of the approach.

There are some upcoming changes that are aimed specifically at making the code easier to maintain and test.


HTML has a lot of implicit newlines we need to deal with.  They exist at the end of block-level elements (block level means they’re elements that exist in their own line).

We call them “visual newlines” because they are only shown to the user in visual mode.

When editing regular content, you can simply edit all of the text nodes involved.  The problem with visual newlines is that editing them means more complicated actions need to take place.

Think about removing the trailing visual newline in a list.  It basically means extending the list to include what’s after it, up to the next paragraph break, and modifying the DOM structure to merge those elements.

We’ve done a lot of progress with handling these visual newlines.  Quite a good amount of effort has been put into making them work, but we think more effort will be needed for specific case we may not have fully considered.

What We’re Really Proud Of

We’re really proud of the work we’ve done to create a generic HTML editing component, that doesn’t feel slow or clunky.  There’s simply no comparison with how it feels when compared to other mobile editors.

The amount of time we’ve put into the architecture has paid off as well.  We still need to improve some sections of the code to make them cleaner and easier to maintain, but for the most part we feel pretty good about the quality of Aztec iOS, and most of the code is properly documented to make it easier to navigate.

The architecture was designed to be easy to write automated tests for.  We’ve been encouraging ourselves to try and write at least one unit test triggering each bug report we get, which has proved to be a key factor in avoiding regressions.



Aztec was inspired by a library called Knife, an open-source text editor. Aztec consists of several key components:

  • AztecText [ GitHub ]
    • Native UI view inheriting from EditText
    • The visual editor component
    • Styled text in a form of Spannable
    • Customizable styling with XML attributes
  • SourceViewEditText [ GitHub ]
    • Native UI view inheriting from EditText
    • The HTML editor component
    • Represents the styled text of AztecText in HTML
    • Customizable styling with XML attributes
  • AztecToolbar [ GitHub ]
    • Native UI view inheriting from FrameLayout
    • Used in conjunction with AztecText
    • Applies text styles in visual mode
  • AztecParser [ GitHub ]
    • Non-UI internal component
    • Translator between AztecText and SourceViewEditText
    • Converts styled text (Spannable) to HTML and back
  • ImageGetter [ GitHub ]
    • Interface for loading images implemented by an external module
    • Supplied by the Aztec library client
    • Not dependent on specific networking stack
    • Two sample loader modules available

All of Aztec’s features & capabilities are used and demonstrated in a sample Demo App, which is part of the repository.


  • Written primarily in Kotlin
  • Developed using the latest release of Android Studio
  • Library minSdkVersion 14
  • Contains almost 350 unit tests

Third-Party Dependencies


  • Consistent and correct Spannable-to-HTML and HTML-to-Spannable parsing
  • List-editing (adding new items, deleting items, closing a list, etc.)
  • HTML element hierarchy & order preservation
  • Visual newlines around block elements
  • Inconsistencies of certain behavior across different Android API versions

Challenges We’ve Faced

One of the biggest challenges for us was avoiding regression errors by implementing new features & bug fixes. For example, things like list or quote editing involves a fair amount of character-level processing. It is key that the element and newline spans are applied to specific locations around certain characters. This system is sensitive to changes, so a small bug fix in one part of the editor often triggered a cascade and broke things in other parts. To help us overcome this we had to write numerous unit tests for every feature and edge case we could think of. It gave us confidence to see the tests passing after changing something and it would have been nearly impossible to progress without them.


We’ve come a long way since starting on the project in June of 2016.

Aztec has been integrated in the WordPress beta release and with every additional feature & bug fix it is becoming more usable in real world applications. We’ve designed the library to be simple to integrate and we’re continuing to work on the plug-in architecture so that it will be even more extensible and customizable in the future.

Help us test the Aztec native editors by using them in your own project and contributing back. Check out the original announcement post under “How should I report?” for more information on how to get involved.

Call for Testing: WordPress for iOS 7.5

The WordPress for iOS 7.5 beta will be available for testing on TestFlight soon. Not part of the beta program yet? Please sign up for our TestFlight program to request to join as a beta tester.

What to Test

1. Aztec Native Editor

You may have heard about the new editor that’s included (but hidden) in the WordPress app. Aztec has reached beta status and you’re being invited to test it out!

First step: Read about Aztec here. There are instructions on how to enable it.

Second step: Look at the release notes for Aztec to find out what works, doesn’t work. It’s a beta so there’s still work left to be done.

Third step: If you test with updating an existing post, you may wish to use a test site. While we’ve been working super hard to make a solid experience you could potentially lose formatting.

We’re keeping the testing scenarios pretty loose at this point:

  • Compose a new post.
  • Update an existing post.
  • Add images (video support coming).
  • Try formatting things and verify formatting isn’t lost after posting.


Something not work right? Did the app crash? Please tell us if something that seems like it should work didn’t.

2. Post Slug editing

On a post you can now edit the post slug (the unique part of a post URL).

Testing steps:

  1. Create a new post.
  2. Tap the ellipsis button and then Options. Tap Slug near the bottom of the list.
  3. Edit the post slug and provide something different than the default. (currently the default is blank – we’re going to supply the standard text before 7.5 ships)
  4. Publish the post and verify the slug is what you provided.
  5. Also try editing the slug on an existing post (using a test post is suggested).


Try and break this – leave it blank, put weird stuff in there, etc. Let us know what happens!

Several Bug Fixes & Improvements

There were a bunch of other improvements made in this release that aren’t being called out in this post. You can view the entire list here.

Bugs & Feedback

Did you find a bug or come up with a feature request while testing? You can discuss it here, ping one of us in the #mobile Slack room, report it using the TestFlight feedback link, or head straight to the iOS GitHub repository and open a new issue.

Thanks for testing!

#aztec, #beta, #ios, #needs-testing, #wpios

Introducing the Aztec Mobile Editors

The hybrid (HTML & JavaScript) approach has worked well enough to bring a rich editing experience to our users. The limitations of the web view has prevented us from giving those users the anything better than a 7 out of 10 experience. The only real solution for us to reach a full 10 out of 10 was to rethink the implementations to get closer to the metal. That means using APIs provided by Apple and Android to make text editing feel like something that was made for the platform.

The mobile team has been hard at work since July 2016 to improve the post editing experience for our users.

Our hope is the Aztec editor is seen as a component that can be used by many iOS and Android apps to provide a rich HTML editing experience. We feel that we could garner a bigger contributor base to the mobile apps simply because this component exists, is free & open, and is super awesome. We’re not biased at all, of course. 🙂

The Aztec Logo

What Does Aztec Give Our Users?

  • Accessibility – Using OS-provided text controls makes every piece of what you can see to be visible to technologies like VoiceOver. We can now properly support our users that require accessibility. Additionally we can now support dictation!
  • Spell Check – Something as simple as spell check is a nightmare to get working properly in the current hybrid editor. No longer a problem with Aztec! This makes the editing experience feel safer for our users.
  • Speed/Performance – Aztec is so much faster and memory efficient since we have control over the small things.
  • Aztec Everywhere – We plan on using Aztec in more than just the editor view. Aztec is actually a text view implementation and lightweight enough to use in many places in the app. Think of being able to send rich text replies to comments and a more robust iOS sharing experience thanks to a fully custom UI.
  • Contribution – We’re packaging Aztec as a component in its own GitHub repository (each platform has its own repo). This makes Aztec something outside users will want to incorporate into their own apps and contribute back to. Quite literally there is nothing like this out there – every editor we could find uses a web view or has very limited support for any HTML.
  • Undo/redo – The Aztec editor supports undo/redo on both platforms. It’s temporarily disabled on iOS until we finalize some bug fixes.
  • Unit Testing – We’re actually able to write unit tests for scenarios that come up and make sure they’re handled consistently. UI testing is also now possible!

What was so Hard?

Editors are hard. I think many of us here working on WordPress can attest to just how difficult dealing with HTML is sometimes. We had a number of technical hurdles to get over. Some of the challenges were:

  • HTML Synchronization/Consistency – Switching between HTML and visual editing mode presents a ton of challenges keeping things in sync. HTML tags that don’t visually alter the rendering need to be retained – dropping that markup would dissatisfy users fairly quickly.
  • Lists & Block Quotes – We’re still having struggles with getting the editing and rendering experience just right with lists and block quotes. They’re deceptively complex and have been one of the places we’re spending the most time on to get right.
  • Amount of Work – There’s just a lot to do with an editor. Edge cases are so numerous that they really aren’t edges. Editors are more like spikey balls on chains.

Okay, I Want to Test it Out!

We wanted to ship Aztec quietly to limit the number of voices providing feedback. The projects aren’t 100% ready for feedback from the full community quite yet but we feel everyone reading this blog can get an early peek. We’d like you to keep some things in mind as Aztec isn’t completely finished on both platforms. We’re not rolling out Aztec to our public beta testers until we’re sure the editing is a beta or better experience.

  1. Aztec is not quite ready for posts where losing formatting would ruin your life. We’re still working out bugs and HTML synchronization between what you see and what ends up on the server is one of the areas we need testing for.
  2. Lists and Blocks aren’t fully finished. Nested lists on iOS aren’t supported yet.
  3. Media support is limited to images. Videos aren’t supported quite yet and images may have some funk with how they’re presented on Android.
  4. External keyboards are supported but not fully feature-enriched. Feel free to use your keyboard with your tablet. Things like the tab key may not be spot-on yet.
  5. You can check out the open issues lists on GitHub to understand what’s left to work on.

Turning on Aztec in the WordPress Apps

You’ll want to become a beta tester for the WordPress app to get access to the newest changes. Join the iOS TestFlight program for Apple devices. Android users can join the beta from the Google Play Store on your device (under “Become a beta tester”).

The next step to using Aztec in the WordPress apps is to unlock it as it’s a hidden feature right now. In the web browser on your device, visit this URL:


This unhides Aztec in settings and turns it on. You can turn the new editor on & off by following these steps:

iOS: To turn on Aztec in WP iOS 7.2 or newer, navigate to the Me tab, tap App Settings, turn on Visual Editor (which should be on already), then turn on Native Editor.

Android: Turn it on by navigating to the Me tab, tapping the App Settings option, tapping the Set editor type setting, and choosing either Legacy or Visual.

Using Aztec Directly

Each of the Aztec repos also contains a demonstration application to use the Aztec component without it being inside of the WordPress apps. If you want to start hacking away on the component itself, this is the best way to start looking at it.


What should I report?

  • Discrepancies between what you saw in the editor and what actually got published – If you lost formatting or had other problems we really want to know.
  • Crashes – any time you get the app to crash whilst in the editor, let us know.
  • Content that freaks out the editor – if you found some HTML that the editors just do not like, let us know. We’re looking to bulk up our unit tests with examples that make things get wonky.
  • Anything preventing you from publishing – specifically on iOS we rewrote the code around the entire editing experience. If you discover state issues that don’t let you tap publish (for example), let us know.

How should I report?

  • GitHub – Report issues to the main WP Android or WP iOS repos. If you know for sure the issue lies with the Aztec component you can report it directly to the appropriate Aztec repo.
  • Slack – We’re hanging out in Slack in #mobile.

What’s Next?

Here’s a list of the milestones we have in the project and approximate dates:

  1. Alpha – Turned on for the development team & testers to dog food. We’re here now.
  2. Closed Beta – When the editor is good enough to advertise to beta testers (turn on w/URL) and to get feedback from them. Starting with WPiOS 7.5 beta & WPAndroid 7.3 beta which equates to April 24th.
  3. Open Beta – When the editor is good enough to unhide the option to be able to turn it on/off for everyone (advertise it to App Store users with the caveat of beta). Ideally shortly after closed beta; May 22nd would probably be the earliest.
  4. Release Candidate – When the editor is good enough to turn Aztec on by default but allow it to be turned off. We’re estimating a month or more of beta time; June 19th+.
  5. Full Release – When Aztec replaces all current editors and legacy code is removed. This is mid to late July or later depending a number of variables.

Closer to the open beta we’ll start focusing on improving documentation for contributors on the individual project repositories. You can also look forward to seeing posts here on technical discussions for both platforms.

Special Thanks!

None of this would have been possible without the hard work of: @0nko @diegoreymendez as technical leads,  @rachelmcr heading up our testing efforts, and @heckofanapp @hypest @klymyam @lanteanar @sergioestevao @mbiais @bummytime @folletto @aerych @koke working on the engineering and implementation.

#accessibility, #announcements, #aztec, #editing, #editor, #native

Call for Testing: WordPress for iOS 7.3

The WordPress for iOS 7.3 beta will be available for testing on TestFlight soon. Not part of the beta program yet? Please sign up for our TestFlight program to request to join as a beta tester.

What to Test

1. Publicize Improvements

If you tried the Publicize feature that came out in version 7.1 you’ll want to take a look at these improvements:

  • Fix a broken publicize connection from the editor’s post options.
  • Switch back to the default publicize message (post title & URL) by deleting the custom message.
  • Tap the whole line (not just the toggle) to toggle a connection on or off.

To test:

  1. In your site’s Sharing section, connect to at least one sharing service.
  2. Bonus: Break the publicize connection (for example, by deactivating the social media account you connected — you might want to use a test social media account for this!).
  3. Create a new post.
  4. Open the post options.
  5. If you broke your publicize connection in step 2, tap the error symbol to fix the connection.
  6. Set a custom publicize message.
  7. Remove the custom publicize message.
  8. Tap anywhere on an individual sharing connection to enable/disable it.
  9. Publish the post and confirm the default publicize message (your post’s title and URL) was used.


  • Did the three improvements work as expected? Please report anything that didn’t work or other parts of the Publicize feature that you still have trouble with.
  • Flow Challenge: Were you able to fix a broken publicize connection and return to your task smoothly? What happens if you change your mind in the middle of the process? Please report any point where you get stuck or can’t find your way back to the post you’re working on.

(Related Github pull requests: Reconnect a broken connection, Switch back to default message, Toggle behavior.)

2. Recent Sites

You can now find your most recently used sites at the top of your site list (under My Sites > Switch Site), if you have more than 11 sites in the app.



  • If you have 11 sites or fewer, does the recent sites section appear? (It shouldn’t appear unless you have more than 11 sites.)
  • If you have more than 11 sites, do your recent sites appear in the order you most recently used them in the app?

(Related Github pull request.)

3. Site Icons in My Sites

Site icons for public sites will now appear in the site list and the site details on the My Sites tab. (Previously, only a site icon placeholder appeared there.)

To test:

  1. Add a site icon to a site (from the site’s general settings or customizer).
  2. In the app, open the My Sites tab.
    1. Check your site list and confirm the site icon appears next to the site in the list.
    2. Open the site details and confirm the site icon appears next to the site title/URL at the top of the screen.


  • Please report any issues with the site icon not appearing next to a public site, either in the site list or on the site’s details (dashboard) screen.
  • Bonus: Try removing the site icon as well as adding it, and confirm the app updates the site icon in both cases.

(Related Github pull request.)

4. Sharing to WhatsApp and Telegram

You can now share posts to WhatsApp and Telegram, using the sharing buttons on the post:

  1. Install and set up WhatsApp and Telegram on your device.
  2. Open the Reader in the WordPress app.
  3. Find a post that has the WhatsApp and/or Telegram sharing buttons enabled.
  4. Tap on “Visit” under the post in the Reader list view.
  5. Scroll down to the sharing buttons under the post.
  6. Tap on the WhatsApp and/or Telegram buttons to share the post.


  • Please report any errors or unexpected results when you share the post to WhatsApp or Telegram.
  • Testing Challenge: Can you find the other ways to share a post from the Reader? Test those out and confirm sharing works as expected in each place.

(Related Github pull request.)

Bugs & Feedback

Did you find a bug or come up with a feature request while testing? You can discuss it here, report it using the TestFlight feedback link, or head straight to the iOS Github repository and open a new issue.

Thanks for testing!

#beta, #ios, #needs-testing, #wpios

Call for Testing: WordPress for iOS 7.1

The WordPress for iOS 7.1 beta will be available for testing on TestFlight soon. Not part of the beta program yet? Please sign up for our TestFlight program to request to join as a beta tester.

What to Test

1. Publicize (Sharing) Support for Posts

You can now manage your sharing connections for individual posts, to control where each post is shared when you publish it. Try it out:

  1. In your site’s Sharing section, connect to at least one sharing service.
  2. Create a new post.
  3. Open the post options.
  4. Set a custom publicize message.
  5. Enable/disable individual sharing connections.
  6. Publish the post.

Voilà! Your post will be publicized to the selected social media accounts, using your custom message.


  • Things to check: Did all of your connected accounts appear in the post options? Did your custom message show up on the publicized post? Was the post publicized to your selected connections (and only the ones you selected)?
  • Flow Challenge: Did the publicize settings make sense in the sequence of steps you took to create your post? Did you ever have to disrupt your publishing process to manage those settings, or did you experience any confusion or frustration along the way?

(Related Github pull request.)

2. Noto Font Update

The Merriweather font has been replaced with the Noto font in the app, to provide better support for non-Latin scripts.

Here’s how it looked before, with Merriweather:

And after, with Noto:


  • Please use the app in your language of choice. Let us know if you notice any overall issues with the font, or specific issues in your language (such as characters not appearing or displaying incorrectly).

(Related Github pull request.)

3. iPad Layout for Notifications

Notifications now have a splitview (sidebar) layout on iPads, similar to the rest of the app. iPhone users should not see any difference in the Notifications layout.


  • Please navigate through your Notifications, interact with them, and report any quirks or bugs in the new layout or behavior.
  • Testing Challenge: Try to catch the Notifications with unexpected layout behavior, especially while rotating the device or multitasking on your iPad.
  • Flow Challenge: Does the new sidebar make the best use of your iPad’s screen? Are there actions in the Notifications that don’t use the layout as expected, or places where you now get stuck?

(Related Github pull request.)

Bugs & Feedback

Did you find a bug or come up with a feature request while testing? You can discuss it here, report it using the TestFlight feedback link, or head straight to the iOS Github repository and open a new issue.

Thanks for testing!

#beta, #ios, #needs-testing, #wpios

Call for Testing: WordPress for iOS 7.0

The WordPress for iOS 7.0 beta will be available for testing on TestFlight soon. Not part of the beta program yet? Please sign up for our TestFlight program to request to join as a beta tester.

What to Test

1. Navigation Arrows for Notifications

You can use arrows (in the top right corner) to navigate through your in-app notifications without returning to the notifications list. (This is designed to match how you can navigate through your notifications on the web.)


  • Check your notifications in the app. Use the arrows to navigate to older or newer notifications. Do the arrows work? Are they disabled when you reach the end of your notifications?
  • Flow Challenge: How do the arrows feel for navigating through your notifications? Were you surprised or confused by anything? Did the navigation feel natural and expected?

(Related Github pull request.)

2. Add Excerpts to Post Editor

You can now add and edit post excerpts directly from the app:

  1. Create a new post.
  2. Open the post options.
  3. Scroll down to the excerpts (bottom of the options screen).
  4. Tap and enter an excerpt.
  5. View the post and confirm the excerpt is being used (e.g. in the Reader list view, in subscribers’ email notifications, or on your site if your theme uses excerpts).


  • Try adding excerpts to new posts, editing excerpts on existing posts, and creating/editing posts without excerpts.
  • Testing Challenge: Compare the app’s excerpts feature with the same feature in the web editor. Do the app and web excerpt features work in the same way? Do your excerpts stay intact when moving between the app and the web?
  • Flow Challenge: Did you encounter any confusion or obstacles adding an excerpt to your post? Does the excerpt act as expected throughout the rest of the app (for example, in your posts list or in the Reader)?

(Related Github pull request.)

3. Better Support for RTL Languages

The app got a facelift for right-to-left (RTL) languages, with an improved layout throughout the app. Check out the pull request for a series of before/after screenshots showing the changes, and try it out:

  1. Open the Settings app.
  2. Go to General > Language & Region > iPhone Language and select an RTL language (e.g. Hebrew).
  3. Open the WordPress app. (Bonus: Log in to a account with the same interface language.)
  4. Navigate through the app and look for any layout issues, e.g. incorrect padding or alignment.


  • Do you speak an RTL language? Please let us know if we missed any layout issues or created new ones!
  • Testing Challenge: Log out and check the login/signup screens. Do they work as expected for the allowed input? Do the error screens look right?

(Related Github pull request.)

Bugs & Feedback

Did you find a bug or come up with a feature request while testing? You can discuss it here, report it using the TestFlight feedback link, or head straight to the iOS Github repository and open a new issue.

Thanks for testing!

#beta, #ios, #needs-testing, #wpios

X-post: WPiOS 6.9 Translation Help

X-post from WPiOS 6.9 Translation Help