Tag Archives: weekly-update

Alex 6:00 pm on August 21, 2013
Tags: , weekly-update   

Code Revisions: Week 9

Version 0.7 is tagged and I am planning to submit it to the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party directory later today or tomorrow.

code-revisions

Viewing code revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. now feels much more native: By default WordPress makes use of normalize_whitespace() before comparing two posts to one another. This results in loss of blank lines and missing multi-space indention as often seen in css files. I fixed this by plugging into the wp_text_diff() function (#302). Further more you now get the correct menu item expanded when viewing code revisions (#316).

Besides those I am still struggeling with syntax checking (#335). Looks like I will be settling for just using ‘php -l’ if available. Problem there is I am still not able to get a reliable path to the php binary. Since PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 5.4 there is the PHP_BINARY constant, so I need a way to get it manually in PHP versions lower than 5.4..

#code-revisions, #weekly-update

Kat Hagan 5:42 am on August 16, 2013
Tags: , weekly-update   

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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party — 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.

#post-by-email, #weekly-update

Alex 3:09 pm on August 13, 2013
Tags: , weekly-update   

Code Revisions: Week 8

I skipped some weeks here; sorry for that. WordPress 3.6 was released and now there is quite some talk about 3.7 and 3.8 ongoing here – I really like the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party approach! It actually is the same approach recommended to us GSoC students for the projects. Many features which can be put together by coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developers when they team up might be essential to WordPress while maybe still not essential as part of core. This way WordPress development could get much more dynamic for the future.

As of the discussion on my last post 0.6 the plugin now primarily uses php -l for syntax checking – if available. If not, I am still falling back to eval (#335).

For the next weeks the plan is now to bring a more code-editor-like look to the code revision viewer: Show indention and lower the line spacing etc. This will need some not so pretty overwriting of pluggable functions because most spaces are stripped for diff-creation.

Further more I will discuss releasing the plugin to the plugin repository with my mentors as preparation to final considerations if or if not this or part of this should get into core.

#code-revisions, #weekly-update

Frederick Ding 12:00 pm on August 12, 2013
Tags: , weekly-update   

Migration update: brief hiatus

I’m glad to see the excitement that the recent 3.7/3.8 discussions are generating. I’ll only write a short update today on the importer.

Since I’ve been moving back to campus and am in the midst of a busy staff training period (as disclosed in my application and timeline), I haven’t been able to get much coding in, and won’t have the time to code new features until next week.

I’ve received some very helpful feedback that led to resolutions, and will continue fixing bugs in the little time I have this week:

  • Undefined index notices (#327 comment:22)
  • Remove UIUI User interface reference to ‘adminadmin (and super admin)’ user (#350, core #24729)
  • FilterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to exclude menu items from import (#349)

(I periodically check old and open tickets on CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. for the importer/exporter to see what I can handle within the scope of this project.)

Meanwhile, I’m also examining the Relocate tool‘s handling of large sites — out-of-memory issues — which will eventually be resolved in the bigger picture by integrating it into the importer or attaching it to WP_Importer_Cron so that it, too, can work on a schedule.

Next Monday, a new betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. of the cron-based importer will be tagged and released for download.

#migration-portability, #weekly-update

Frederick Ding 5:16 am on August 6, 2013
Tags: , , weekly-update   

Migration update: try this importer

Hey everyone,

The importer is largely unchanged from last week, with the exception of a few UIUI User interface changes:

  • #341: Progress for posts/attachments/menu items is now shown correctly (in %d of %d format)
  • #342: The debug view (showing the raw data) now uses print_r through a special chars filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.
  • #340: UI now has full-sentence strings to communicate how the process works and when the import is done, and Refresh/Abort buttons are shown above and below the progress.

An import of a WordPress WXR file in progress

A completed WordPress import

I’ve also had the chance to run it against a large number of import files, including ones sent to me by generous volunteers who read some of my previous weekly updates (props @tieptoep). No catastrophes, yet!

Obviously, it’s still a work in progress, but I’m now willing to risk a public betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.. The usual disclaimers (please don’t use this on a production siteProduction Site A production site is a live site online meant to be viewed by your visitors, as opposed to a site that is staged for development or testing.) apply.

Although I’m not aware of any other plugins that build on the WXR importer through its APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., I nevertheless generated some PHPDoc API documentation using phpDocumentor 2, which might be handy if you decide to hook into this or reuse its components.

I’d love to hear your feedback on the interface, on the general experience using this importer, and any errors or warnings that you encounter. Thanks!

#importers, #migration-portability, #weekly-update

Kat Hagan 8:16 am on August 2, 2013
Tags: , weekly-update   

Post By Email Update: Horde library!

After much wailing and gnashing of teeth, I was finally able to get the Post By Email pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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 SSLSSL Secure Sockets Layer. Provides a secure means of sending data over the internet. Used for authenticated and private actions. and IMAP connections (without requiring PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 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 translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. 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 HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. 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.

#post-by-email, #weekly-update

Frederick Ding 3:33 am on July 30, 2013
Tags: , , weekly-update   

Migration update: cron importer part 2

Hey everybody — I have good news and bad news.

Good news: I’ve finished porting all the individual import steps to the cron model and now have a mostly working frontend UIUI User interface (largely unchanged from the previous iteration of the importer) that utilizes it.

As of this evening, the cron model is able to parse, process, and finish importing two test XML files from the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. unit tests (valid-wxr-1.1.xml and small-export.xml). The test case, which uses exactly the same assertions as the core unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression., passes all 193 assertions. (Update: an errorless import of the wptest.io sample data has been done.)

WordPress import in progress

WordPress cron import in progress

A completed cron import

A completed cron import

Bad news: I wanted to tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) a version and release a download today, but I’ve decided not to do so due to the unconfirmed stability of the importer. As some astute observers noted last week, storing the temporary data in the options table can blow out caches. Although I’ve attempted to mitigate this (see [2180] and this reference from a few years back on Core Trac), I still need to test this against some real systems before I release it and break your server.

Those who are very interested can always check out the source in Subversion. I will post a comment under this post if a download is made available before my next weekly update.

Although an overhaul of the XML parser, as suggested in the comments on last week’s post, is probably necessary to avoid memory and caching issues, my first priority was to finish the migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. of processes to the cron tasks. As soon as I can post a working importer, I will immediately turn my attention to the XML parsing step.

#importers, #migration-portability, #weekly-update

Kat Hagan 5:24 am on July 26, 2013
Tags: , weekly-update   

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 blogblog (versus network, site) 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 WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. this weekend, be sure to say hi!

#post-by-email, #weekly-update

Alex 6:23 pm on July 25, 2013
Tags: , weekly-update   

Code Revisions: Week 5

Week 5. Two days late.. I wasn’t happy with what I got on Tuesday and did not want to post yesterday because of other internship posts. Well, I’m still not happy with my progress on syntax checking. Maybe I can get some constructive feedback on this: When I initially proposed this project the idea of preventing faulty code of being saved came up. It is easy to break an installation with some bad changes to a php file of an active theme or pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. Obviously, a broken installation is a bad user experience.

The problem I ran into when investigating this is that it is not that easy to check php syntax from within php. There was a function in php coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. itself which got removed some versions ago. The current implementation of this in version 0.5 of my plugin uses eval – I know eval is evil, but it doesn’t matter because you can do what ever evil you want to when you’ve got access to the editors:

ob_start();
var_dump(eval("return true; if(0){?>{$code}?><?php };"));
$error = error_get_last();
ob_end_clean();

This still does not catch all errors, but it at least gives me the ability to notify about  unbalanced brackets and missing quotes. The problem here is that some shared hosts might have it disabled by default.. Any thoughts on alternatives?

Next week is evaluation time and I will be doing some testing on different installs. Because this functionality for the moment is intended to only work with WordPress 3.6 this shouldn’t bring up to many problems. Happy WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. everyone in SF!

#code-revisions, #weekly-update

Frederick Ding 12:03 am on July 23, 2013
Tags: , , weekly-update   

Migration update: cron importer

Following last week’s update about the WP_Importer_Cron approach to writing importers and running import jobs, I’ve been steadily transitioning code from the current non-stateful, single-execution pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to a stateful, step-wise process (#327).

At the same time, I needed to separate presentation from logic/backend processing (#331) — something that @otto42 also recommended — in two ways:

  • Removing direct printf(), echo statements that were used by the WXR importer (example)
    and changing them to WP_Error objects (example of fatal error; of non-fatal warning)
  • Handling uploads and UIUI User interface choices in a separate class

Why must this be done now? Well, asynchronous tasks differ from PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher scripts directly responding to a browser request — we can’t depend on having access to submitted $_POST data, nor can we directly pipe output to the user. This change would also make it easier to understand what the code is doing from reading it, and to test programmatically.

One dilemma I’ve encountered: how best to store the parsed import XML file. Since each step of the import (users, categories, plugins, etc) runs separately, we must…

  1. store all of the parsed data in variables, which are serialized into an option between runs
    (obviously, a huge amount of data for which this may not be the most robust or efficient method);
  2. re-parse the XML on each run
    (currently, parsers handle all parts of the XML at once, which means unnecessarily duplicated effort and time);
  3. modify the parsers to parse only part of the XML at a time; or
  4. split the XML file into chunks based on their contents (authors, categories, etc) and then feed only partial chunks to the parser at a time.

Any thoughts? Solving this problem could also help the plugin deal with large XML files that we used to need to break up by hand before importing. (The Tumblr importer doesn’t have the same problem because there is no massive amount of data being uploaded at the beginning.)

I haven’t yet finished transitioning all the steps; I’m afraid it won’t be possible to use this just yet. Before next Monday, I should have a downloadable plugin that’s safe to try.

#importers, #migration-portability, #weekly-update