Helping with development

[Dave Widmer]

Hi all-

My name is Dave Widmer, the Web Applications Developer for Bowling
Green State University and my boss has taken an interest in the
Anthologize plugin for digital preservation for our university blogs.

I have been in touch with Patrick Murray-John and he directed me to
this list, so I thought I would introduce myself and show my interest
in helping with the development with this plugin.

After taking a look through the code and the databases I have a few
questions to throw out.
----
1. In the wp_options table there are 2 difference anthologize options,
anthologize_settings, which holds the version info for the plugin and
anth_settings which holds the minimum cap info for running the plugin.
Any reason for the 2 different entries?

2. What are the benefits for having anthologize_meta for each post in
the wp_postmeta table? It looks like all of the info stored can be
taken from the regular metadata that Wordpress saves.

3. Every time a post is added to a part in the project editing screen,
the wp_post database is adding 2 revisions to the project. This is
going to make the post database grow large, fairly quickly. Has there
been any thought in storing the project and parts information in their
own tables? This would also help with cleanup in the case of
uninstalling the plugin.

4. Any interest in a MVC pattern for this plugin?
------

Thanks!
Dave

[Boone B Gorges]

Hi Dave,

Thanks for your interest. I think we'd all be very happy to have another
dev on board.

Off the top of my head, some responses to your questions:

> 1. In the wp_options table there are 2 difference anthologize options,
> anthologize_settings, which holds the version info for the plugin and
> anth_settings which holds the minimum cap info for running the plugin.
> Any reason for the 2 different entries?

This is an oversight. They could be combined.

> What are the benefits for having anthologize_meta for each post in
> the wp_postmeta table? It looks like all of the info stored can be
> taken from the regular metadata that Wordpress saves.

When an item is added to a project, it becomes an anth_library_item. We
copy the entire thing, with the idea that we are creating a snapshot of
that item at the time it was copied; future changes to the source post
should not be reflected in the Anthologize project. The same can be said
for the data being stored in anthologize_meta. Stuff like post author
can be changed in the original post, but we want the Anthologize post to
be a reliable indicator of what the item looked like at the moment of
import, including the metadata stored in anthologize_meta.

Another minor consideration is that storing the data in postmeta related
to the anth_library_item provides a performance advantage over looking
it up dynamically at runtime from the source post. WordPress
automatically caches all postmeta data related to the currently queried
posts (which is to say, anthologize_meta is made available at the time
of export without requiring an additional db query). Pulling the data
dynamically from the source post would either require a costly JOIN, or
a bunch of small get_post_meta() calls on uncached post data.

> Has there
> been any thought in storing the project and parts information in their
> own tables?

We store it in the wp_posts table because we're making use of
WordPress's "custom post type" framework, which stores data in the
wp_posts table and differentiates it using the post_type column. Using
this framework provides us with many benefits:
- we get to use the native WP editing interfaces for individual posts,
with no additional code required
- we automatically take advantage of caching and other performance
enhancements that site admins have instituted on their local installations
- the data becomes accessible (and writable) via WP functions that are
very familiar to the vast majority of WordPress developers
(query_posts(), WP_Query, the_author(), stuff like that), which expands
our potential development audience by orders of magnitude
- it's the recommended way to store data, per WP recommendations

Moving to our own custom table would mean moving away from the Custom
Post Type framework, which would mean giving up on all of these
benefits. If site administrators are concerned about SQL performance on
very large datasets (which probably doesn't have to happen until there
are many millions of entries in the database, even in somewhat modest
environments, since WP's post query stack is pretty well optimized for
this kind of performance), there are a number of system-level ways they
might get performance boosts, such as good query caching and a
persistent object cache.

It might be worth discussing, as a team, whether it makes sense to allow
users to disable WP's auto-saving of revision history for Anthologize
content, as this would certainly decrease the db load. I'm definitely
against doing it across the board, though, as built-in revision history
was one of the big plusses of using WP's custom post types in the first
place.

> Any interest in a MVC pattern for this plugin?

I don't have any objections to this, especially if it would help to
clean up what is pretty frequently a mess of code (written mostly in six
days, ahem :) ). I will note, though, that MVC purism usually ends up in
frustration when developing WordPress plugins, because WP itself, and
its plugin APIs, are not built in a way that encourages it. That said,
patches welcome :)

Please feel free to fork the project on Github and send any pull
requests our way! And thanks for your interest.

Boone

[Dave Widmer]

Boone-

Thanks for the info!

I'll stick with the internals for how projects/parts and posts are
saved to keep with the standards that are in place by Wordpress
already. I figured as much, I just wanted to check in.

I've already forked the repo (https://github.com/BGSU-LITS/
anthologize) and am hacking away. I have a feeling the front-end is
going to be a major rewrite so I'll keep you updated on the project
info and send pulls when I hit milestones.

I'm also moving over towards a cleaner class based system. I don't
know if I'll be able to fit the MVC into Wordpress as you mentioned,
but I'll see what I can do.

Looking forward to diving deeper into the project and I'm sure I'll
have questions.

Dave

[Dave Widmer]

Does anyone have a sample output file for the HTML format?

I'm to the point to building out the API to access the data, but just
wanted to make sure my output matches what is currently there. When I
rollback my changes the HTML output is breaking on some of the
themeing functions.

Thanks
Dave