[wp-hackers] Strider Core plugin framework

[scribu]

Erm...there's no code in the Google repo, just the directory structure.

On Tue, Mar 17, 2009 at 8:47 PM, Stephen Rider <wp-hackers at striderweb.com>wrote:

> Hi all --
>
> This has been in the works for a while, and it's not complete, but going by
> the "release early and release often" philosophy...
>
> I'd like to introduce you to Strider Core.
>
> http://code.google.com/p/strider-core/
>
> Straight from the readme and source:
>
> Strider Core is a framework for use in other plugins.  It is not a plugin
> unto itself.  It includes many points of minor functionality and polish,
> such as Settings page links from the Plugins page, and an attribution in the
> footer of the Settings page.  A significant feature is the ability to
> activate integrated version checking for plugins not hosted on WP-Extend.
>
> Strider Core also has an interesting feature in that if multiple plugins
> are built on it, they will all use whichever is the highest version present.
>  Thus, upgrading one plugin can improve all of the Strider Core plugins.
>
> NOTE: This framework is still in early development, and thus
>        functions may not be entirely stable.  There is no guarantee
>        that later pre-1.0 versions will be backward compatible.
>        As a public framework, consider it alpha, folks!
>
> How Strider Core versioning works:
>  * Every Strider Core plugin loads its own strider_core.php file.
>  * The first strider_core.php to be loaded creates the load_strider_core()
>        function, and sets it to run on the plugins_loaded hook.
>  * For each strider_core.php file, the __FILE__ and version (above)
>        are loaded into $this_strider_core[], and then passed into
>        the $strider_core_info[] array.  $this_strider_core[] is unset.
>  * After all plugins are loaded, load_strider_core() runs, in which
>        $strider_core_info[] is UNset, and the strider_core.php
>        file with the highest version is loaded again
>  * This time, the strider_core class is created.  (also, $strider_core_info
>        is recreated, with data for the current strider_core file only)
>  * Finally, the list of Strider Core plugins is looped through
>        and each SC plugin "main" file is loaded.  Those files are
>        the heart of their respective plugins.
>
>  In the end, you are left with:
>        * global $strider_core_info[], which == the $this_strider_core
>                array from the top of the active core only
>        * global $strider_core_plugins[] -- keys are the plugin
>                basename and ['core file'] the "main" file full path for
> every
>                active Strider Core plugin
>        * ...and of course, the strider_core class
>
> Known Limitations:
>        * "main" plugin file isn't called until plugins_loaded hook.  This
> is soon after normal plugin load, but some things do happen before that.
>  Such as...
>        * activate and deactivate hooks don't work from the "main" plugin
> files, because those files aren't called until after those hooks are fired.
>
>  * Future compatibility note: If an upgrade is ever significantly
>        non-backwards compatible, we can simply create load_strider_core_2()
>        which will only load legacy SC1 code if needed.  The code that
>        hooks plugins_loaded will also un-hook the old load_strider_core()
>        as needed.
>
> Known Issues:
>        * The Version Check routine is not complete.  Fully WP integrated,
>        but lacks the actual code that goes and checks a server for a new
>        version.  You can test by upping the version returned by
>        filter_set_update_plugins()
>
>        * As it is set up currently, the register_version_check_header()
>        function is dependent on http://trac.wordpress.org/ticket/8964
>        (Though it is not yet used in this beta -- it will be called
>        from filter_set_update_plugins() )
>
>        * You can't use activate or deactivate hooks, as neither the
>        strider_core_b1 file, nor the "main" plugin file, are called as of
>        actual plugin activation/deactivation.
>
> To Do:
>        * Fix activate/deactivate hook problem.  Probably can hook a simple
>                "container" function from the main plugin file.
>                * see core_activate function
>
> Each Admin page should have a second tab for "Strider Core" universal
> settings:
>        * Toggle Version Check (default true)
>                * Toggle - include compatible non-Strider Core plugins
>        * Toggle menu icons
>
> Version Check routine:
>        * TEST INPUT of "Version Check URI" w/ wp_kses();
>        * fetch latest versions --> TEST INPUT of returned string w
> wp_kses()
>        * after_line_$plugin hook:
>                * "skip this version" button ? (use nonces)
>                * "Disable updates for this plugin" button ? (use nonces)
>        * update_plugin may be written twice per check (in WP) - once for
> update
>                time, and once for actual results.  Only run our update
> routine once!
>
>
> /* License:
>        Strider Core is released under a modified GPL2 license.
>        The modification is as follows:
>
>        1. If you make _any_ changes to the code, other than for purposes
>        of private testing, you are required to change all in-code instances
>        of the string "strider_core" -- do a search/replace and replace
>        "strider_core" with something unique, e.g. "<yourname>_core".
>
>        2. Do not perform the above replacement using anything containing
>        "strider_core".  That is, don't call it "strider_core_2" or
>        "my_strider_core" or something.  If you modify it, it isn't
>        Strider Core, so really rename it.  (Yes, something very much like
> this
>        has happened in the past.  Somebody branched a program of mine and
>        renamed it by adding a "2" to the end. :-\ )
>
>        3. File names and directory names must be similarly altered
>        per #2.
>
>        4. If you do not do the above (#1, #2, and #3), then Strider Core
>        MUST NOT BE MODIFIED IN ANY WAY.
>        This is important, because otherwise your modifications could
>        adversely affect plugins or software *other than your own!*
>
>        --
>
>        If you make modifications and come up with something good,
>        please let me know -- I may add it to the original.  :-)
>
>
> Regards,
> Stephen Rider
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>



-- 
http://scribu.net