Make WordPress Core

Tagged: post-by-email Toggle Comment Threads | Keyboard Shortcuts

  • Kat Hagan 1:47 pm on September 23, 2013 Permalink
    Tags: post-by-email,   

    Post By Email: OPW is over! 

    I can hardly believe it, but my summer internship is drawing to a close.

    This week, I released version 1.0.4 of the Post By Email plugin, comprised of minor bugfixes, tests, and documentation as I prepped the project for its evaluation phase.  I’ve added quite a bit of info to the readme page, including better installation and configuration instructions.

    Those of you following along on Trac may have noticed that I’ve kind of run out of tasks.  🙂

    Today is the official end of the OPW and GSoC programs, so I’ll be taking a short break from development work during the evaluation period.  But this isn’t goodbye!  I definitely plan to stick around and continue working on and supporting this project in the future — so keep those bug reports coming!

    I do want to take a second to thank all of you for being here for me as I learned the ins and outs of WordPress this summer.  I feel really good about where this project landed, and I know it’s because I had so many amazing resources every step of the way.  So, to everyone who left me comments, answered my questions on IRC or Twitter, reviewed my code, tested, reported bugs, offered suggestions, spoke at WCSF, or even just edited a Codex page or wrote a quick tutorial now and then: THANK YOU.  It really made the difference in those moments when I felt frustrated or overwhelmed.

    I don’t know exactly what the future holds, but I do know that I love being a part of WordPress, and I’m excited to continue working with y’all.  Let’s keep in touch.  🙂

  • Kat Hagan 8:44 am on September 6, 2013 Permalink
    Tags: post-by-email,   

    Post By Email Plugin: Version 1.0 is live! 

    I just released version 1.0 of the Post By Email plugin, which includes the following updates:

    • Support for IMAP and SSL connections
    • Option to “mark as read” instead of deleting messages after posting them (IMAP only)
    • Only fetch unread messages (IMAP only)
    • Added contextual help to the admin panel
    • Support for HTML-formatted emails
    • Under the hood: refactoring, bugfixes, properly checking nonce for AJAX requests, etc.

    I also made some changes to the Core patch and added it to the corresponding Trac ticket for community review.

    Please do install and test this version and let me know how it goes!

    This plugin is in beta; the usual caveats apply.  Please be sure to back up your data and/or run this against a test email account.

    As always, you can download the plugin from the official repository or from the Github mirror.

    • Scott Taylor 3:33 pm on September 6, 2013 Permalink | Log in to Reply

      turns out, the New York Times newsroom has a lot of interest in this feature – we’ll probably take a look at this soon

    • Alex King 5:25 pm on September 6, 2013 Permalink | Log in to Reply

      Where do you want to receive bug reports? The plugin just downloaded and created posts from 500+ read emails from an account (creating 500+ duplicate posts) while the old core functionality would only create posts from unread emails?

      • Kat Hagan 6:54 pm on September 6, 2013 Permalink | Log in to Reply

        Yikes! Here is fine, there’s also the support forum on the plugin repo and the Github issues page.

        Are you using POP3 or IMAP? The old functionality worked only with POP3, which doesn’t have a notion of “unread”. So it would post everything in the inbox (read or unread), and then delete all messages afterwards. This is still how POP3 works; if you connect via IMAP, it should post only unread messages.

        Note also that if you connect via POP3 and tell it not to delete messages, it will post duplicates every time it checks mail (once per hour). The settings page is confusing in that regard — it really shouldn’t allow you to select that option unless you’re using IMAP.

        • Alex King 10:33 pm on September 6, 2013 Permalink | Log in to Reply

          I was using the core system before. I enabled the plugin and used the same mailbox but specified IMAP instead of POP3. It found all the old, already imported emails. This is using a Gmail account.

          • Kat Hagan 10:43 pm on September 6, 2013 Permalink | Log in to Reply

            So, that’s odd for two reasons:

            1) There should not BE any “old, already imported emails”. The existing Core functionality imports and then deletes all messages from the inbox. It doesn’t do any kind of tracking of which messages have already been seen/imported. You’re definitely migrating from Core and not a plugin like Postie?

            2) With IMAP it should definitely be using the SEEN flag to only load up unread emails.

            Ohhhh… I may have just figured this out, at least partially. It would’ve imported your existing settings on plugin activation, and checked for new mail right away using those settings (so one check via POP3) before you changed the settings to use IMAP. Then if you checked again after changing the settings, IMAP would’ve just gotten the unread messages — which explains there being two posts for each of the new messages.

            But that still doesn’t explain why there were a bunch of messages in the inbox that had already been imported.

          • Kat Hagan 10:08 pm on September 8, 2013 Permalink | Log in to Reply

            So, thinking about this, I don’t think it’s actually possible you were using the old functionality with a Gmail account, because Gmail requires a secure IMAP connection — the Core functionality only supported non-SSL POP3. That being said, I’d love to figure out how to better support migration from your setup.

            I think one thing I’ll do is add a delay after activation that forces the user to verify the plugin settings before it does a mailbox check for the first time. Obviously doing a straight migration isn’t going to work in all cases.

    • Alex King 5:26 pm on September 6, 2013 Permalink | Log in to Reply

      Where do you want to receive bug reports? The plugin just downloaded and created posts from 500+ read emails from an account (creating 500+ duplicate posts) while the old core functionality would only create posts from unread emails?

    • Alex King 5:29 pm on September 6, 2013 Permalink | Log in to Reply

      It also created 2 posts for each new (unread) email. Could the core functionality still be active as well?

      • Kat Hagan 6:51 pm on September 6, 2013 Permalink | Log in to Reply

        (Duplicate comment, sorry. Comment form was misbehaving.)

      • Kat Hagan 6:56 pm on September 6, 2013 Permalink | Log in to Reply

        Did you patch Core? Otherwise, yes, the old wp-mail.php would still run. Also look at the log in the Settings and see how many times it actually checked — if it checked the mailbox twice, that could explain the duplicates.

        Thanks for helping me test this out!

        • Alex King 10:32 pm on September 6, 2013 Permalink | Log in to Reply

          I think you could have the plugin disable the core checking by using the `enable_post_by_email_configuration` filter.

          • Kat Hagan 10:39 pm on September 6, 2013 Permalink | Log in to Reply

            Well, it’s a bit more complicated than that, because the (unpatched) wp-mail.php checks that filter BEFORE doing the “wp-mail.php” action. So if the plugin returned false for that filter, it would also disable the ability to trigger a manual check by hitting /wp-mail.php.

            My first thought is that, when you activate the plugin, it should delete the global options — then Core wouldn’t have anything to do even if it was called. But that’s a non-reversible change (unless deactivating the plugin saved the options back to the global scope, which doesn’t really make sense in most cases).

    • Alex King 5:35 pm on September 6, 2013 Permalink | Log in to Reply

      The post creation from HTML emails is a welcome new feature though. 🙂

  • Kat Hagan 7:27 am on August 30, 2013 Permalink
    Tags: post-by-email,   

    Post By Email weekly update 

    This week, I finally released the Post By Email plugin into the official repository, which inspired me to do a lot of incidental cleanup (readme files, test instructions, etc.).

    I finished updating the Core deprecation patch for 3.7 — it’s in the plugin repo and will be submitted back to Trac once my mentors get a chance to review it.  (Comments and feedback welcome!)

    I also powered through the remaining infrastructure tasks.  The latest version is 0.9.9 (look how close that is to 1.0!  SO CLOSE) and includes the following:

    • Improved error and status logging
    • Scheduled mail checks via wp_cron
    • Prettified settings page (with stuff like consistent date/time display)
    • Autoloading of Horde library files (HT to ryanmccue for the example)

    If you happen to have access to an unsecured POP3 mail server and want to test this and see what breaks, I’d love to hear about it.  (Be sure to patch Core with the deprecation patch first to avoid weird behavior.)

    The 1.0 release will include IMAP and SSL, at which point I will start requesting beta testers in earnest.

    I just spent the last few hours tracking down a bug in my clear_log function, which turned out to be caused by the Settings API validation function being triggered when an AJAX function (called from the settings page, but not with a form submit) called update_option.  I worked around that, but haven’t yet figured out why it’s happening at all — any insights would be appreciated.

    • pescadito01 7:51 am on August 30, 2013 Permalink | Log in to Reply

      Can i apply as 1.0 beta tester?
      Best Regards, Pescadito

    • Konstantin Kovshenin 9:14 am on August 30, 2013 Permalink | Log in to Reply

      Oh hey there!

      The thing is that once you register_setting with a sanitize_callback argument, WordPress adds a filter on sanitize_option_{$option_name} which runs every time an option is updated, via an admin page, or front end, or XML-RPC, etc., or as in your case – an AJAX handler. This means that your post_by_email_validate will run every time update_option runs, regardless of the context.

      Your hack during the validate function:

      $options['log'] = $input['log'];

      I haven’t tested it, but it looks like somebody can easily write anything to that log by hi-jacking the settings form. I may be wrong though.. In any case, taking the log out of the main options array may be a better idea, since you don’t want to autoload it on every request anyway – logs can get big over time. Also note that logging in that fashion can cause some race conditions because of the way the object cache works with options.

      I don’t know what your end goal with logging is, but I’d suggest looking at PHP’s error_log which can easily be written to wp-content/debug.log in WordPress.

      Hope that helps!

      • Kat Hagan 4:46 pm on August 30, 2013 Permalink | Log in to Reply

        That’s exactly what I was missing, thanks!!! I knew the hack was terrible but I honestly just needed to check something in last night so I could write this post. 😛

        The log originally started out as a separate option, but George recommended adding it in to the main settings array in an earlier code review. Maybe he can weigh in on this?

        The log is meant to be user-facing (i.e. not just for debugging) — it’s a record of any errors that occurred but also status messages (like “Got 3 emails” or “No emails found” or whatever). So I’m not sure using error_log for that makes sense.

        • George Stephanis 11:14 pm on August 30, 2013 Permalink | Log in to Reply

          Now I’m rethinking myself. As you’re not going to load the log on 99%+ of page views, it’d probably be better as a seperate option with autoload turned off. Save some bandwidth between the db server and wp, as well as avoid loading it all into memory.

    • Jen Mylo 2:26 pm on August 30, 2013 Permalink | Log in to Reply

      The deprecation patch should be put on a trac ticket for community review rather than in the plugin repo (which I see isn’t really “the plugin repo” but your own github repo where your’e doing the work). Can you put it on a trac ticket? Thanks.

      • Kat Hagan 4:41 pm on August 30, 2013 Permalink | Log in to Reply

        Hi Jen, I didn’t really want to put the patch back into Trac until Justin and George got a chance to look it over, as I’m pretty sure there are changes that will need to be made. I’m hoping they’ll have a chance to review before our next meeting on Tuesday.

        The Github repo is actually a mirror of both the plugin repo and the GSoC repo, so, yes, it’s in the plugin repo too. 🙂

  • Kat Hagan 5:51 am on August 26, 2013 Permalink
    Tags: post-by-email, ,   

    Post By Email: Roadmap for the final stretch 

    I met with my mentors this past week to hash out the spec for the final iteration of the Post By Email plugin.  It can be found here; I’m updating it as I finish tasks, as well as tracking them in the GSoC Trac.

    This week, I tested under PHP 5.2 and made a few small changes to the Horde library files to support both 5.2 and 5.3 (the Horde framework requires a minimum of 5.3).  I also refactored the admin-specific methods (adding menus and so on) into their own class, which is loaded only if is_admin().

    Of the original feature list, we’ve decided that supporting multisite is currently out of scope (though it may well work anyhow — it’s globally disabled in Core for a multisite install, but I can’t think of any reason to restrict it for the plugin).  Attachments and comment reply via email are on the “nice to have” list, meaning I might not get to them (at least, not before the official internship period ends).

  • Kat Hagan 5:42 am on August 16, 2013 Permalink
    Tags: post-by-email,   

    Post By Email: Getting back on track 

    It has sadly not been a very productive couple of weeks in Post By Email land — I’ve been struggling to balance conferences, travel, illness and other obligations, and ultimately hit that not-so-fun point of needing to take a few days off because the more work I tried to do, the less I was able to do.

    The good news is, I’m regrouping and made a few updates to the plugin — mostly minor fixes and code style cleanup.  This coming week, I’m planning to work with my mentors on the final roadmap of additional features that will be implemented between now and the end of September, so I will have that to share with you next week.

  • Kat Hagan 8:16 am on August 2, 2013 Permalink
    Tags: post-by-email,   

    Post By Email Update: Horde library! 

    After much wailing and gnashing of teeth, I was finally able to get the Post By Email plugin working against the Horde IMAP Client Library.

    It’s a bit of a hack right now — I still need to clean up the code and pull a lot of it out into helper functions — but with this in place, I’ve laid the groundwork for supporting SSL and IMAP connections (without requiring PHP to be compiled with IMAP support).

    A couple of technical oddities…

    • The Horde framework is massive, and while the IMAP library is available as a standalone PEAR package, it still has a ton of dependencies to the rest of Horde.  I solved the problem in a quick-and-dirty way by copying any missing files into the plugin’s includes directory.  Horde uses an autoloader to include the classes it needs; I’m planning to experiment with that, but for now I just wrote a wrapper (so I only have to include one file in the plugin class).  (Does anyone know whether autoloading plays nicely with WP?)
    • Instead of copying over the translation classes, I stubbed out one of them in a “bogus” way that uses WP’s translation functions instead.  Might poke around and see whether I can do this with any of the others, as well.

    The good news is that, once I got this working, I was able to scrap the whole preexisting deal with reading each message line by line and processing it with (buggy) regexes… and move to letting Horde abstract parsing out headers, decoding MIME, etc.  This will also make it much easier to deal with HTML emails, attachments, and so on in the future.

    For now it still supports only POP3, but unlike the previous iteration, it doesn’t lose all the text and create blank posts — certainly an improvement.  🙂

    Next steps: Refactor check_email into helper functions and add support for IMAP, then SSL connections.

    • Peter Chester 4:27 pm on August 2, 2013 Permalink | Log in to Reply

      I’m really excited about this! I’ve wanted to write a cleaner version of Postie for years now (not to knock Postie – I love it, but it’s really buggy). Thank you for working on this Kat!

    • scribu 7:09 pm on August 2, 2013 Permalink | Log in to Reply

      `spl_register_autoload()` works fine.

    • Ryan McCue 6:27 am on August 5, 2013 Permalink | Log in to Reply

      I’ve written many autoloaders (bbPress Reply by Email is a good example) for WP plugins. Best practice is to check that it’s one of the classes you’re actually looking for, since there may be many autoloaders in plugins.

      Once you’ve done that, just map the class to a file; I use PSR-0, which is basically just replacing underscores with a slash then loading it up. WP usually replaces underscores with a dash, then prefixes “class-” instead. Either works, but I prefer the former (and most libraries probably use it, so you can most likely reuse this if you need more libraries).

  • Kat Hagan 5:24 am on July 26, 2013 Permalink
    Tags: post-by-email,   

    Post By Email playing hooky this week 

    It’s been a long week and I’m in the midst of a few things that just aren’t quite working yet. Normally my inclination would be to stay up late hacking it into shape and writing a blog post… but today, it’s more important to me to get to bed early so I don’t miss any sessions at WCSF tomorrow!

    Post By Email will return to regularly-scheduled updates with a longer one next Thursday. In the meantime, if you’re at WordCamp this weekend, be sure to say hi!

  • Kat Hagan 7:08 am on July 19, 2013 Permalink
    Tags: post-by-email,   

    Post By Email Update: POP/IMAP libraries, Trac questions 

    Rather unexciting update this week, as I’m still in the midst of a few things (and have been distracted by caring for a cat who had some teeth pulled… poor kitty!).

    As I mentioned last week, in reading through old Trac tickets, I learned that the POP3 class we’re using to read emails was originally copied over from SquirrelMail.  I’ve been digging into their SVN repo in hopes of being able to adopt (1) an updated POP library that might include fixes for some of the bugs we’ve found, and (2) an IMAP library that we can similarly adapt to our own uses.

    It’s an interesting adventure trying to reconstruct years of history from bug tracker and commit logs… at any rate, it appears the POP3 library originally came from a SquirrelMail plugin called “mail_fetch”, which was since merged into SquirrelMail core.  Complicating matters, the file was renamed from class-pop3.php to class.mail_fetch.php.  But I did ultimately track it down!

    However, while the development branch of SquirrelMail now has “some plumbing” to support remote IMAP servers, I’m not sure whether any of that code will be useful for our needs — it’s not just still under development, but much more intertwined with the rest of SquirrelMail’s code, as opposed to being a standalone class.  At this point I’m more inclined to go with a different library, and have been researching alternatives; the top contender right now is the Horde IMAP library, which also includes an abstraction layer for POP3 (but I’m open to suggestions, if anyone has a favorite).  In the next week, I plan to load that into the plugin and see if I can get it working to support a wider variety of mail servers.

    In other news, I’ve found myself fighting with Trac a lot lately.  I’m curious how all y’all keep track of tickets — both existing ones that you want to receive notices about, and new ones coming in that might be relevant to your interests.  Do you have custom searches bookmarked, an RSS feed, something else?  Please share any tips!

    • Ryan McCue 7:21 am on July 19, 2013 Permalink | Log in to Reply

      I keep forgetting to mention, I have a bbPress Reply by Email that might be interesting if only for the architecture, as I’ve tried to make that delivery-system independent. There’s also some HTML to text (basically a superset of Markdown) conversion code that you might find useful.

      I’m curious how all y’all keep track of tickets — both existing ones that you want to receive notices about, and new ones coming in that might be relevant to your interests

      I have a post on how I handle that, which basically just highlights posts that I’m CC’d in. I also have other filters with things like `Body contains “Component: External Libraries”` that adds a different tag.

      • Kat Hagan 1:28 am on July 24, 2013 Permalink | Log in to Reply

        That firehose post is basically exactly what I wanted, thanks! Guess I might have to take the plunge as well (haha) and sort it all out with Gmail filters.

        Also bookmarked that bbPress plugin, cheers. Think so far I’m doing as much reading code as writing it for this project. 🙂

    • Joppe 7:41 am on July 19, 2013 Permalink | Log in to Reply

      It might be worth looking at the Postie plugin. It has both POP and IMAP support and is actively maintained. Should be a fairly robust implementation of the protocols.

    • Julien 8:13 am on July 19, 2013 Permalink | Log in to Reply

      What about SwiftMailer : http://swiftmailer.org/
      I’ve never played with it but it looks like it has all features you need and it is also used by popular php frameworks like symfony and laravel…

    • John Blackbourn (johnbillion) 9:22 am on July 19, 2013 Permalink | Log in to Reply

      I’m curious how all y’all keep track of tickets

      First of all you’ll need to make sure you’ve set your email address in your account on Trac. Just go to Preferences and it’s right there.

      If you want to subscribe to email notifications on a ticket then you should enter your Trac username into the ‘CC’ field on the ticket. This means you’ll be notified of any new comments. Note that when you leave a comment on a ticket you will automatically be subscribed without having to use the ‘CC’ field.

      Secondly, there’s an RSS feed link at the bottom of every ticket screen and ticket listing screen on Trac. You can either sub to comments on an individual ticket, sub to the main feed on the Timeline screen or go to View Tickets and click a Report or do a custom query and sub to the RSS feed there.

      Hope this helps.

      • Kat Hagan 1:31 am on July 24, 2013 Permalink | Log in to Reply

        Yeah, I think I’ve already CC’ed myself on most of the relevant ones — but then occasionally I find an old one I missed. RSS feeds for custom searches is an awesome pointer, thanks!

    • Bryan Petty 5:57 am on July 20, 2013 Permalink | Log in to Reply

      Like Ryan and many others here, since I’m interested in all tickets, I subscribe to the “firehose” of wp-trac and wp-gsoc lists, however, I do need additional filters on those to highlight important ones.

      Since I use Gmail, a simple filter on usernames are very useful since not only will they catch your own comments without worrying about subscribing anywhere, but they also catch anywhere someone else mentions your name on other tickets too. For example, I’m particularly interested in Ryan’s activity as well, so I have a filter to star messages with this: “list:wp-gsoc.lists.wordpress.org rmccue”

      • Kat Hagan 1:32 am on July 24, 2013 Permalink | Log in to Reply

        Thanks, I’m on Gmail too. A little scared to go the firehose route, but sounds like it’s manageable with some filter magic.

    • Graham Armfield 1:22 pm on July 23, 2013 Permalink | Log in to Reply

      I like to keep watch on the accessibility trac tickets so it’s useful to build custom queries. You can mould your views by changing around the query string – sorting on particular elements, including certain columns etc, etc.

      For example my regular query to find all accessibility tickets is:

      I have all these saved as bookmarks and I guess you could add the ones you want onot Delicious etc.

      Hope that helps.

      • Kat Hagan 2:36 am on July 24, 2013 Permalink | Log in to Reply

        Yeah, I think I’m going to go the custom query route, too. I might try them as RSS instead of bookmarks and see how that works out. I’ve also found things I cared about that didn’t necessarily get assigned to the “post by email” component.

        BTW, since you’re involved in accessibility, do you happen to feel like weighing in on this? https://core.trac.wordpress.org/ticket/23684#comment:10

        It’s a very minor change, but it happens to be the ticket I adopted as my first-ever WordPress patch, so I’d like to see it get accepted. 🙂

  • Kat Hagan 9:04 am on July 12, 2013 Permalink
    Tags: post-by-email,   

    Post By Email Weekly Update 

    This past week, I continued delving into the mysteries of unit testing, and ended up submitting a minor patch back to the unit-tests repo (after spending some time trying to figure out what was wrong with my setup that was causing one of the tests to fail on core).

    The Post By Email plugin now has working tests for activation, but not yet for the main functionality, which will require further research to learn how to mock out email retrieval.  (I’ve back-burnered this for the moment.)

    I also spent some time wandering around Trac, and learned that a problem I’ve been having is actually an ancient bug, which I then tracked down to a misbehaving regex that is supposed to determine the charset of the email.  It requests that iconv transform the given text into the garbled charset, gets nothing back, and proceeds to cheerfully create an empty post.  I haven’t fixed it yet, as I’m hoping to replace large swaths of that code with a new library anyhow (apparently we originally got that POP3 library from SquirrelMail, which does now support IMAP and SSL, so that’s the first place I’ll look unless there are other recommendations).

    Finally, I collated the plugin’s status and error messages into a mini-log, and added a quick status overview to the settings page.  I also put a “check now” button in the settings.  Right now it just logs the result of the most recent check; ultimately I plan to show a longer history, and also organize/format the messages better (errors color-coded, links to posts, etc.).

    I tweaked a few more things about my setup this week, and am now mirroring the plugin source on Github, if Git happens to be more your cup of tea.

    Next, I’m focusing on developing a patch to deprecate Core, and vetting existing plugins to ensure backward compatibility.

    • mighty_mt 4:37 pm on July 12, 2013 Permalink | Log in to Reply

      Last year I actually reported another ticket about this “missing content” problem in Trac (see https://core.trac.wordpress.org/ticket/21554). I also included a fix there but I think it might be a good idea to do a more comprehensive rewrite of the code after.

      Just a question. Will the new plugin still include the “wp_mail_original_content” filter? I have written a plugin that hooks into this filter which I’d have to adapt otherwise.

      • Kat Hagan 10:30 pm on July 12, 2013 Permalink | Log in to Reply

        Aha, awesome! Thanks for pointing that out — I’m still struggling to figure out how to effectively find things in Trac.

        As for filters, yes, it will still call “wp_mail_original_content” to filter the content, and core will also continue to call the “wp-mail.php” filter for plugins that want to override the entire functionality. The concern about backward compatibility is more for any plugins that might be loading up wp-mail.php directly.

  • Kat Hagan 6:48 am on July 5, 2013 Permalink
    Tags: post-by-email,   

    Post By Email update: tests and multiple WP versions 

    First off: After I mentioned last week that I needed a POP mail account to test with, several folks with their own mail servers offered their help.  I’m set up with something now.  Thanks to all who reached out!

    The past week has been all about testing, with the goal of getting good unit and/or integration tests written for the Post By Email plugin before I start adding features to it.  This is entirely new territory for me, though I’ve done some TDD in Ruby in the past.  So far, I’ve learned how the tests work on Core, and gotten a whole mess of things installed and running (wp-cli, Pear, PHPUnit, etc.).  I followed this guide to set up the basic test structure for the plugin.  I was hoping to have some actual tests done for this week’s update, but it took a bit longer than expected to get the framework set up, so I don’t have anything ready for primetime yet.

    So, this week’s question: What are some plugins that have really good tests?  I’m seeking examples of what to do (or not to do!).  I’m especially curious to see tests of Settings API stuff and install/activation functions.

    Side note: I really need to clean up my development setup for testing against multiple WordPress versions.  I have several versions installed already, but they’re pretty haphazard (with different databases, inconsistent directory names, etc.).  I found this very good post about a development setup with multiple WP versions.  For those of you who support plugins or themes on multiple versions — any tips?  Is your setup similar to that post?

    • George Stephanis 6:51 am on July 5, 2013 Permalink | Log in to Reply

      I normally work off a checkout of trunk, but it’s easy to switch from one version to another by doing something like svn switch https://core.svn.wordpress.org/tags/3.4.2 — which would switch you to that branch. The dbDelta calls will normally migrate your db properly to make sure it’s running right.

    • Kat Hagan 6:58 am on July 5, 2013 Permalink | Log in to Reply

      Oh, duh, can’t believe I didn’t remember the old versions are tagged in svn! I’ve been using git-svn, since I prefer to use git for local revisions, but it’s not clear to me how it interacts with svn tags (if, in fact, it works at all). I’ll have to play with that.

    • Brandon Kraft 3:09 pm on July 5, 2013 Permalink | Log in to Reply

      If you’re using the Github repo as a base, at least, tags sync over well: https://github.com/WordPress/WordPress/releases

      Personally, I heard the rule of thumb was current-1, so 3.5 and 3.4 branches would good to maintain now. Once 3.6 drops, then that and 3.5, etc.

      With this being something new, I would think you wouldn’t need to go too far back for back compat.

      • Kat Hagan 6:58 pm on July 5, 2013 Permalink | Log in to Reply

        Hmmmm. I did not know about the Github repo. The instructions for contributing to Core only have the SVN one. So, thanks for that — clearly I should just switch over instead of trying to interact with the SVN repo with Git.

    • Bryan Petty 7:18 pm on July 10, 2013 Permalink | Log in to Reply

      Since you mention you’re using git-svn, it’s also possible to setup your plugin with Travis CI for automated tests against multiple WP versions (and multiple PHP versions). This can help show you how to set this up: https://github.com/tierra/wordpress-plugin-tests

      If you’d like to continue using the WP-CLI route (and you can still do this while adding Travis CI), you’ll need to re-adapt some bash scripts and Travis CI config options based on these:



    • Nikolay Bachiyski 12:02 pm on July 11, 2013 Permalink | Log in to Reply

      I usually don’t test version older than trunk locally, but instead defer to Travis.ci, since I rarely need the short feedback loop of a local testing for older versions.

      If you use wp-cli‘s scaffolding it will generate a .travis.yml for you. Also, here is a working config testing various PHP and WordPress versions.

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