Have you taken the WordPress 2013 Survey yet?

WordPress.org

Make WordPress Core

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Ryan McCue 1:20 pm on July 17, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    JSON REST API: Version 0.3 

    Time for another release of the JSON REST API! We’re closing in on midsemester evaluation, so it’s time to get our test on and ensure that everything’s working well. Only small updates to the API itself this week, but also the first introduction of the comment API:

    • Add initial comment endpoints to get comments for a post, and get a single comment (#320)
    • Return a Post entity when updating a post, rather than wrapping it with useless text (#329)
    • Allow filtering the output as well as input. You can now use the json_dispatch_args filter for input as well as the json_serve_request filter for output to serve up alternative formats (e.g. MsgPack, XML (if you’re insane))
    • Include a profile link in the index, to indicate the JSON Schema that the API conforms to. In the future, this will be versioned.

    The big part of this week is the introduction of the testing suite and reference client. These are now both available on GitHub and I’d love for you to run them and test out the API. There’s currently one known bug that causes one of the tests to fail, which I’ll be handling in 0.4 due to the large scope of the issue.

    I’m planning to continue work on the test suite this week, due to the large scope of the testing suite. Ideally, I’d like to get up around the 90% mark for code coverage (which I’ve done previously on my Requests library), however I’m not sure as to how coverage can be measured in this case, so I’ll also be investigating this. The coming week will also involve creating a Backbone-based sample theme as a proof-of-concept of real world use. In addition, coming up I’ll be consulting with Max Cutler from the mobile team and ensuring that any possible issues are sorted out at this early stage.

    As always, I appreciate all and any feedback on the project. This week and the next will be boring for you guys in terms of new features as we approach midsemester review, so I’d love you to get out there and break the API. If you can find problems with it, please file them and let me know so I can work them into the testing suite.

     

  • ahoereth 8:09 pm on July 16, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Code Revisions: Week 4 

    Version 0.4 of the Code Revisions plugin is out. If you used a prior version you might need to manually remove posts of the post type code and post meta fields with the key _code_revisions. Uninstall and upgrade functionailty which removes/refreshes this stuff automatially will of course be integraded in later versions.

    Main new feature this week: Taking direct file changes through ftp or plugin/theme updates into account (#303). A new revision is automatically created and the user is notified with an admin notice:

    This file changed in the meantime.Not sure about the text there yet ;) But this can be changed later on. A problem I ran into here was that I need to approach this from a plugin point of view and cannot hook into core in all places I would possibly like to. The intial idea was to save a file’s last modified timestamp (using filemtime) and check it when ever viewing the file in the editor again. Problem is the file is written right before the page is redirected – which is why I cannot get the file modified time after the file was written. So now I am using md5-checksums of the file’s content instead. This results in an additional file read to generate the checksum (using md5_file) every time an editor is being viewed – again, this could be avoided if I could check the sum after the file is read for being used in the editor. If this functionality gets into core I will need to move to one of the more direct approaches.

    Another thing which did cost me quite some time to find out: The time points revisions are created by core changed. I mostly try to stick to core functionality and for creating revisions only used wp_insert_post and wp_update_post – revisions were created automatically. Now this behavior was changed for wp_insert_post (#24708) and I did need to adjust a little bit (#324). This now results in a new problem because the first two revisions are created in the same second and therefore considered to both be the currently “live” revision (#326). Most simplest way might be to apply some JS to reactivate the button. Need to look into this.

    Midterm and with it “feature completeness” is moving closer. Next on my list is to prevent user’s from breaking their installation through fatal errors.

    See you next week, I would appreciate testing and maybe some bug reports! Thanks!

     

  • Frederick Ding 12:00 am on July 16, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Migration update: WXR importer 

    This week, I began work on the next phase of my project: fixing up the WXR importer plugin. A number of developers, including Jon Cave, Peter Westwood, and Andrew Nacin have been maintaining this plugin since at least May 2010.

    I forked the code from the plugins repository into my GSoC Subversion directory in preparation. It’s taken a while to test this (manually) against XML files from existing sites, so that I can see under what circumstances it fails to complete the import or perform to expectations, and what can be done. Trac tickets and forum posts have been informative as well. (See the linked posts for the results and observations.)

    I’ve also run the unit tests that apply to the importer plugin; however, the test cases are generally small (indeed, the biggest XML test case is 26 KB, titled small-export.xml) and don’t trigger the kinds of issues that importing dozens or hundreds of posts and attachments—with WXR files of megabytes in size—does.

    So, the first task at hand is breaking up the process—which currently executes in one step with little indication of progress—into discrete chunks that can run in separate, stateful (stepwise) requests.

    A chat with my mentors has pointed me in the direction of WP_Importer_Cron, which was first developed for other importers that need to make external API calls (e.g. Tumblr Importer) potentially subject to rate constraints. There are some parallels between “external API calls” and “remote attachment fetching”, which is why this can be a suitable approach for fixing the timeout issues that present with the current WordPress importer. After the process is discretized, showing progress (an enhancement long overdue) will be easier.

     

    • dllh 1:07 pm on July 16, 2013 Permalink | Log in to Reply

      I’ve worked quite a lot with imports and am glad to see you doing some work on this front. One of the problems I think you’ll wind up running into with attachment handling is backfilling. You have to maintain a list of attachment ids and their parents, and the ids can change as the import process goes on and would-be id collisions are averted. Further, there are sometimes images that are referenced in posts but not attached to them. So a backfill process that takes these things into account is important.

      So farming fetching itself out to cron isn’t going to solve the problem, though it may help with timeouts. Some issues I foresee:

      • On sites with little traffic, the images will basically never import, or people will perpetually file bug reports that it’s not finishing, when in fact, they just need a few hundred visits to cycle through fetching all their images.
      • There’s no built-in way to track status of a given image. If you try to use something like options to track status, you’ll wind up with too-big options (potentially bad for sites using memcached) or find that race conditions prevent proper saving of the data.
      • What happens if images start to be processed before the import itself is done? This becomes an issue when an attachment that appears near the top of the export is fetched before a post near the bottom of the export that references it is fetched. A backfill process that’s timed with the image fetch won’t yet have that late post to check for a reference to fix up.
      • What happens if the import is halted partway through? This wreaks havoc with backfilling in particular.

      It occurs to me (I’m shooting from the hip here, so it’s not terribly well thought-out and may be stupid) that you could possibly register a custom post type to get around some of these issues. The process would look something like this:

      1. When the import starts, a unique taxonomy term in a taxonomy registered to the new CPT is created.
      2. Every time the importer encounters an image, it creates a new post of type CPT containing relevant data and with the unique taxonomy term applied. No fetching is done yet. (Or, fetching is done in the background and a post meta is toggled to represent the state of the image progress. So on initial creation, it’s “pending,” when the fetch is in progress, it’s “downloading,” then it becomes “pending_backfill,” then “backfilling,” then “finished” (and “failed” when applicable, which could possibly be useful in diagnosing and fixing issues with the import after the fact — as the CPT data will include post parent, a nice little list of problematic posts could be generated so that the user could fix things up rather than just hoping for the best).
      3. When the importer is finished, it queues a cron job to check for posts of type CPT in the given taxonomy with the unique term.
      4. That job fetches N CPTs at a time and fetches/backfills them (after changing their status in meta so that future jobs don’t scoop them up). If there are any left, it fires another job to get the next batch. Maybe there’s an option stored to prevent doubling up on jobs (or to allow multiple jobs without collision).
      5. When there are no more CPTs with the unique taxonomy term, the import is finished, and the status screen can be updated and an email sent.
      6. If fetch/backfill jobs seem to be languishing, we can report it on the status screen, and perhaps, if they seem to have been stalled for a while, we can have a button you can push to manually fire the job off and kickstart the process.

      I think something along these lines would allow for better display of data about the status of the import as well as less brittle handling of attachments. It won’t necessarily be the fastest process in the world, and the implementation of a CPT for these purposes feels a little weird to me, but otherwise, I’m not sure there’s a great way to track the status of attachments without running into issues with either option sizes or race conditions (trust me — I’ve dealt with this).

      For what it’s worth, I’m not a fan of javascript-driven approaches. JS is fine for polling the status and updating the UI, but as the thing that triggers and tends the process, it seems weak. What if you close the page and the js hasn’t managed to store proper state remotely, for example? Better to have something that runs properly whether you’ve got the import page loaded or not.

      Well, that was a mouthful. Even if my napkin proposal is a crackpot idea, maybe it’ll spark some useful thoughts. Good luck with it. :)

      • Samuel Wood (Otto) 10:48 pm on July 16, 2013 Permalink | Log in to Reply

        WP_Importer_Cron handles a fair amount of the cron work by making the entire import happen as a cron process. Essentially, I first wrote it not because of rate limits, but because a) you run into the time limit on PHP processes when you have a lot of work to do and b) Tumblr is slow as heck in responding to API requests.

        The way you use it is to make your importer class extend WP_Importer_Cron. It gives you some functions to help with this sort of thing.

        • First is save_vars(), which essentially saves your class’s variables to the options table for usage on the later instantiations. Thus, you can save your progress as class variables, then just call save_vars after each step (like after you import a post, for example). This keeps track of your progress. On later runs, your vars are automatically loaded into the class instance for you, putting you back where you were.
        • Next is have_time(), which simply says whether you’re out of time or not. If it returns false, then you’ve exceeded 30 seconds (default) and you need to stop doing things for now.
        • There’s also schedule_import_job( $callback, $args ), which you can call when you’re ready to begin the import. It schedules a job to run every minute, and it will keep running once a minute (or so) until the job is done. How does it know you’re done? Well, you give it a function callback to do the actual job of importing. When that function returns true, the job is considered complete and the cron schedule is removed.

        So what WP_Importer_Cron gives is a way to start a job to run once a minute, a way to check for current run time expiration, and a way to save internal class variables persistently from one run to the next. Plenty enough to build a long-running process on for importing things slowly. You can use a separate importer class from the user-data-gathering pieces, if you like, for simplicity of purpose. Or you can combine the two like the Tumblr Importer does. I’d recommend the first one, the Tumblr Importer is a bit confusing in that respect.

        • Frederick Ding 11:20 pm on July 16, 2013 Permalink | Log in to Reply

          Hey @otto42, thanks for chiming in here!

          Your clarifications for how (and why) WP_Importer_Cron works are really helpful — I wrote some notes for myself earlier today for what I figured by reading its source.

          If you don’t mind, I’ll also write some PHPDoc for the class and its methods building on what I now know, as I start separating pieces and extending WP_Importer_Cron.

          • Samuel Wood (Otto) 6:18 pm on July 17, 2013 Permalink | Log in to Reply

            Don’t look too awful much at how the Tumblr Importer works. It’s not great in that respect. Instead, think about how your process should work and then just use those three functions from the class to run periodically. You’ll probably have better luck that way.

      • Frederick Ding 11:16 pm on July 16, 2013 Permalink | Log in to Reply

        @dllh Wow, thank you for an incredibly thought-out suggestion — there’s a lot to digest here.

        From what I’ve digested of the Tumblr Importer and WP_Importer_Cron source, it stores a counter of the number of posts and other objects imported thus far and the number in total — in an option. I suppose this isn’t as comprehensive as what you’ve proposed with the custom post types — but I’m also not comfortable creating so many transient objects… definitely something to think about.

        As for backfilling: from what I can tell, in WXR files where everything was exported, attachments come first (in another case, attachments and menu items were mixed together but all before posts). I’m not sure whether this is just in the case of the two exports I looked at, or if there is a rationale for this order.

        Certainly the exporter takes great care to make sure that categories and taxonomies are exported with parents before children — I’m not quite certain why attachments would necessarily come before posts, especially in the import process, when posts are necessarily their parents.

        Thanks to WP_Importer_Cron, which suggests a way to hold progress on the server side, the JavaScript would only be for polling the status (and making at least enough requests for cron jobs to be triggered). It wouldn’t be responsible for holding state at all. I need to write a separate response to @otto42, whose comment was just posted as I was writing this.

        Thanks for your input! There’s a lot to be considered.

    • Shea Bunge 11:39 pm on July 16, 2013 Permalink | Log in to Reply

      You should definitely check your importer with the http://wptest.io test data – it’s pretty much the most complete set of test data avaliable.

      • Frederick Ding 3:43 am on July 17, 2013 Permalink | Log in to Reply

        Great resource! Definitely will. I’m assuming that all of the attachment URLs referenced are directly accessible (for attachment fetching)?

  • Kat Hagan 9:04 am on July 12, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    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 http://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.

  • Andrew Nacin 2:14 pm on July 11, 2013 Permalink | Log in to leave a Comment
    Tags:   

    The WordPress.org support forums were taken offline this morning to help resolve data corruption and uptime issues with a database cluster, which had caused intermittent downtime across the WordPress.org network. All problems have been resolved and the support forums have been brought back online.

    You can follow a new status.wordpress.org blog (hosted elsewhere, on WordPress.com) for future status messages. (You can subscribe to that site via email.)

     

  • Ryan McCue 1:57 pm on July 10, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    JSON REST API: Version 0.2 

    It’s that time of week again folks (and actually on-time this time)! Version 0.2 of the JSON REST API includes my changes from the past week, including:

    • Allow all public query vars to be passed to WP Query – Some private query vars
      can also be passed in, and all can if the user has edit_posts
      permissions (#311)
    • Pagination can now be handled by using the page argument without messing
      with WP Query syntax (#266)
    • The index now generates links for non-variable routes (#268)
    • Editing a post now supports the If-Unmodified-Since header. Pass this in to
      avoid conflicting edits (#294)
    • Post types and post statuses now have endpoints to access their data (#268)

    You can also view all changes if that’s your style.

    As you can see, it’s a bit of a quiet week in terms of new features, but with the exception of revisions, attachments, and comments, the post API is now considered feature complete. Implementers can now expect that there won’t be any major changes to the post API.

    Since you’ve all been so great, I’ve thrown in a bonus for this week. I’ve created a small proof-of-concept of extending the API for a multisite installation, which is now available via GitHub. Keep in mind that this is just a proof-of-concept, so it doesn’t have too much implemented. (This is also not covered under the scope of the GSOC project, so pull requests are most welcome!)

    In the next couple of weeks, development will be focused around creating tests and example implementations. While this is occurring, I plan to also implement commenting, which was not in the original scope, but is still fairly important.

    As always, feedback is welcome!

     

  • Mark Jaquith 6:29 am on July 10, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Hey! Remember that WordPress 3.6 release we were working on? Yeah… we’re still at it. But there’s hope! Post Formats UI has been extracted, and Revisions has gotten an intense refactoring that makes it scale up to hundreds of revisions without killing your server or your browser. A backlog of many hundreds of tickets has been whittled down. As of this writing, we’re below 40 tickets for 3.6, and they’re actively being committed and punted as appropriate.

    The plan is to keep on those tickets and get to RC by Friday. Help is appreciated! A bunch of people have been “pinged” regarding tickets on report/6, so please scan through those and log on to IRC to check for messages.

     

  • ahoereth 4:59 pm on July 9, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Code Revisions: Week 3 

    Week 3 of GSoC: Half-way to midterm and half-way to feature complete beta.

    The last week was about restoring code revisions (#296). There again the problamatic part was how differently WordPress handles themes (#306) and plugins (#307). By now I am actually considering to streamline the two editor files (theme-editor.php and plugin-editor.php) using a general code editor class. Espacially plugin-editor.php does some weird stuff: The plugin query var for example often contains the last viewed file instead of the plugin’s main file. There are actually already multiple trac tickets regarding stuff like this. But this would be out of scope of my project – maybe something for after midterm, depending on the project’s progress.

    Until next tuesday I will teach the plugin to pay attention to direct file changes through ftp or theme/plugin updates (#303). Users should be able to see how their own changes were overwritten. This is of special interest when the user intends to reimplement his own changes or wants to check if bugs he fixed are now fixed officially.

    If you are interested you can test version 0.3, report bugs and follow on further progress on trac.

     

    • George Stephanis 5:04 pm on July 9, 2013 Permalink | Log in to Reply

      Apologies if it’s already been asked and answered, but do you intend to distinguish between file changes due to upgrading a plugin, and the user changing the file on their own somehow?

      • ahoereth 8:40 pm on July 9, 2013 Permalink | Log in to Reply

        It is not intended to create a revision of every file edit. The revisions are intended for in-editor edits only. But to keep a clean record of changes the plugin will check if the file has changed since the last edit and if thats the case it will create a new revision of the file and notify the user.

        So no, no distinguishing between direct and in-editor file changes. But we only log them if there has been in-editor changes to this file before.

  • Frederick Ding 12:57 am on July 9, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Migration update: WP Relocate 

    This past week, I’ve focused primarily on bringing a usable interface to the WP_Relocate class that I posted about last week. While the WP_Relocate class file itself was meant to be something that could be bundled into another suite and reused, the fruits of this week’s labour come in the form of an installable plugin.

    In actuality, the plugin hooks are very shallow — merely used to add a menu link (for now). The most important part is the practically-standalone interface.

    WP Relocate UI

    The design intent was to make this look and feel just like the installer — or the upgrade.php script for database schema changes.

    This has been tested against 3.5.2 and 3.6 only. Despite differences in how these versions handle revisions, the changes made to post content are still revertible in either version:

    Revisions tracking search and replace

    I can test this in code to my heart’s content (except for the difficulties using the current unit-tests framework against older versions of core) but nothing beats running it on live site data, especially sites that have posts and uploads from earlier versions of WordPress. As you might imagine, live data is more difficult to generate and test against. I don’t yet know how well this process works with hundreds or thousands of posts, in terms of the time it takes and the level of verbosity communicated to the site administrator.

    If you’re interested in trying this out (please don’t use it on a production site — it’s probably not ready for that), feel free to:

    It installs into wp-content/plugins. The included readme.html file contains more detailed instructions. If anyone tries it out, I’d love to hear if it broke your site. :)

    What’s next? This week, I am forking the importer plugin that works with WXR files, to examine and fix its issues with fetching attachments from the source. I hope to add some ability to replace URLs using the WP_Relocate class to smooth out the process of copying content from another installation.

    Edit (2013-07-09): updated to 1.0.1 with fix for PHP versions before 5.4.0.

     

    • Brad Touesnard 1:25 am on July 9, 2013 Permalink | Log in to Reply

      Hi Frederick, I’m curious, have you taken a look at http://wordpress.org/plugins/wp-migrate-db/? Or the pro version for that matter? I haven’t dug into your code yet, but it sounds like you’re doing some great work here. Keep it up!

      • Frederick Ding 1:31 am on July 9, 2013 Permalink | Log in to Reply

        Hi Brad, I had come across the site for WP Migrate DB pro version while researching, but hadn’t seen the free edition. It looks like your plugin is very useful for producing a database dump for export!

        I think I have a slightly different use case in mind. The utility of this plugin is that it’s “in-place”. But in reality, all of this is merely a preface to later improvements that I’ve planned for the WXR-based importer/exporter. The plugin UI helps me to do all of the testing that unit testing won’t cover!

        Thank you for your encouragement!

    • Ryan McCue 1:31 am on July 9, 2013 Permalink | Log in to Reply

      This looks fantastic! I’m a big fan of the decision to use revisions; have you given thought to creating an undo functionality? (This would probably mean also storing copies of option data, which could be expensive.)

      • Frederick Ding 1:34 am on July 9, 2013 Permalink | Log in to Reply

        Thanks! Indeed, I’ve thought about a rollback ability (after all, things can go wrong when it’s iterating over all the posts and options).

        It might not be as expensive as one might imagine: one would only need to store copies of options that have changed, and we could probably clear all transients when running the process in either direction. (Darn, I wish I had thought of skipping transients earlier.)

        • Ryan McCue 2:46 am on July 9, 2013 Permalink | Log in to Reply

          It might not be as expensive as you might imagine: one would only need to store copies of options that have changed, and we could probably clear all transients when running the process in either direction. (Darn, I wish I had thought of skipping transients earlier.)

          I hadn’t thought about that either; great idea!

    • JakePT 5:36 am on July 9, 2013 Permalink | Log in to Reply

      This looks great! But can I use it to move a site from, say http://website.com/old to http://website.com/new?

      I just tried something similar and got this error:
      “Error: The old site URL provided cannot be used in the replacement process”

      Should also note the accompanying PHP error:
      Warning: preg_match_all() expects at least 3 parameters, 2 given in /home/demomagi/public_html/package/wp-content/plugins/relocate/class-wp-relocate.php on line 299

      • Frederick Ding 6:20 am on July 9, 2013 Permalink | Log in to Reply

        Hey Jake,

        Thanks for your feedback. My bad! I was following PHP documentation for preg_match_all not realizing that the 3rd parameter didn’t become optional until 5.4.0, hence the error in older versions of PHP. And yes, WordPress needs to work with PHP as old as 5.2.4 (that was from 2007!). I’ll make this correction and update the download immediately.

        But to answer your first question, yes, you absolutely can use it for that replacement. It was just the PHP preg_match_all compatibility issue that threw off the URL validation.

    • Shea Bunge 5:36 am on July 9, 2013 Permalink | Log in to Reply

      A word of warning: be careful when getting the user to directly access a .php file from the wp-content directory – lots of users block direct access to these files. It might be better to hook to template_redirect and check for a custom query var, and load your interface there instead.

      • Frederick Ding 6:12 am on July 9, 2013 Permalink | Log in to Reply

        You’re right about the issues with that — disabling direct access to .php files in wp-content is a sensible security approach (although plugins and themes do sometimes use direct access — such as in the case of timthumb and CSS minifying plugins).

        The issue with hooking into something like template_redirect is that I’m not sure it would load early enough. The script somewhat needs to operate independently of WordPress because it can’t rely on the “old” site URL to work — just as upgrade.php and install.php do — and the other possible alternative is to ask that users drop this file elsewhere (as Ryan suggests when using the JSON API as part of core).

    • mattyrob 1:01 pm on July 11, 2013 Permalink | Log in to Reply

      Hi Frederick. This looks like a very worthwhile project to me. I’ve just repaired a whole bunch of corrupt serialized data for attachments in the postmeta table for two of my site that probably came from a previous version of WordPress (I can’t think it was a plugin as I’ve never used a media plugin).

      Anyway, I needed to use wp_update_attachment_metadata() and wp_generate_attachment_metadata() to apply the fixes quickly and effectively.

      I’m replying as I note in 1.0.1 of your code you are using wp_insert_attachment() to update some of hte postmeta but the codex for that function indicates that the above 2 functions should be called as well. I thought you might want to look at that for rebuilding the attachment postmeta while you fix up the other table entries.

  • Kat Hagan 6:48 am on July 5, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    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?

     

← Older posts

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel