This is the second major slimming patch for mp-wp1 and the result is a streamlined mp-wp roughly half the size of the original genesis, all without removing anything that actual people actually use. The following are the stats for this patch:
| Before | After | Reduction | |
|---|---|---|---|
| Lines of Code | 138,088 | 89,186 | 35.4% |
| Bytes on Disk | 4,923,363 | 3,060,6652 | 37.8% |
Since this was more than a simple find ./mp-wp/ -iname "*.js" | xargs rm, it's worth outlining what exactly was removed/changed in this patch:
- ALL JS and JS related code has been removed, including inline JS, PHP used to load JS, as well as code related to popups and other elements generated by JS.
- The JS widget to edit categories inline while editing a post has been removed. You can select existing categories for your post but to manage them (add/delete) you must navigate to the category page. Tags can be specified as a comma-delimited list and new tags will be created on save.
- JS warning alerts have been removed (e.g. "are you sure you want to delete this?), to mitigate against accidental deletion, in-row delete links for Posts have been removed.3
- Inline editing ("quick edit") and bulk editing has been removed from tables, as this relied on JS. Bulk edit can be achieved directly via MySQL.
- The notion of media "attached" to an article is gone, as this relied on the JS popup modal for selecting and attaching media. Based on the survey it also seemed like no one really used this feature, instead relying on their own scripts for generating the HTML code to insert images into articles. Removing the media upload interface entirely was discussed, but in order to support the multi-author use case it was decided to keep this around for now.
- Interfaces for modifying themes and plugins have been removed. Similarly interfaces for adding/deleting plugins has been removed. All of these features still work the same way you're probably used to using them already, by modifying files on the filesystem directly.
- Any function in
wp-includes/deprecated.phpthat wasn't called anywhere has been removed. In a future patch the rest of these could probably be removed. - The no-op
wptexturize()function (defined inwp-includes/formatting.phpand all calls to it have been removed. - The Adobe Flash file uploader has been removed.
- Theme "functions" have been removed, except for registering sidebar widgets. I would've liked to have removed that as well but simply couldn't muster the will to do it in this patch.
In addition to the above I also decided to clean up the admin UI a bit and give it, what I thought to be, a much needed facelift:
- The
wp-admin/images/directory has been removed. This contained base64 encoded PNGs, saved as SVGs, for use as icons in the admin interface. Along with this, the entire admin interface has been given a minor but comprehensive facelift4. - All "widgets" have been removed from the Dashboard except for the overview, recent drafts, and recent comments widgets.
- Bulk action rows below tables have all been removed. They just weren't necessary since long pages are paginated anyway.
- The
wp-admin.cssfile was moved fromwp-admin/towp-admin/css/, where all the other admin CSS lives. - All "rtl" CSS has been removed.
This site has been running on this patch for the last 24 hours, and I've been banging on it locally for the last month or so. However, as always, you should backup your db and site directory before deploying this or any other major changes to mp-wp. If you have a custom theme, it should work fine as is with these changes. Likewise, if you're using any plugins not included in the trunk of mp-wp, they should work as well.
Feedback/additional testing is welcome and appreciated. This is a big change so I want to make sure everything works as expected for all current mp-wp users.
Patch and Signature
mp-wp_remove-all-javascript.vpatch
mp-wp_remove-all-javascript.vpatch.billymg.sig
- After the first, which removed TinyMCE. [↩]
- of these remaining bytes, about 220k are dedicated to empty directories not removed by V. [↩]
- Should they be removed in all tables? In some cases this means adding "Delete" buttons to single-item views where they previously were only present in the list view rows, e.g. in the Media Library. [↩]
- The ability to select a color scheme for the admin UI, and all associated code, has also been removed. [↩]
Thinking to finally give this a try and I've been working on reducing my deviance from the standard functionality. How does one edit the sidebar widget layout with this change? I've used the JS-based drag-and-drop (wp-admin/widgets.php) for lack of known alternative.
Apologies for the late reply, just seeing this now (given my low activity on this blog lately I also don't check in as frequently on the incoming comments, of which there aren't many).
The widgets still work, and you can still customize the settings for each one similar to how you would in the JS-ified UI, however reordering is something I must have overlooked. Without drag-and-drop the only way (currently) to reorder them is by updating the `sidebars_widgets` row of your `[blogname]_options` table in the db. Otherwise they will keep the order in which they were added (so I suppose to reorder you could also remove the widgets and re-add them in the order you like, individual widget settings would be preserved since each one has its settings stored in a different row of the `_options` table).
TBH, I think this feature should be removed in favor of simply editing `theme/sidebar.php`, and I considered removing it in this patch but decided against it since it would've been a breaking change for existing sites. Though if it were removed in a future patch you would still be able to use all of the existing built-in widgets by calling their methods in `theme/sidebar.php`. For example: adding the line `<?php wp_widget_recent_comments(); ?>` would include the same recent_comments widget that is used by the existing "Dynamic Sidebar" feature.
I hope the above is helpful and I would be happy to hear what you think re: removing the dynamic sidebar feature in a future patch.
Those are some dreadful workarounds though, don't you think? I mean, my "sidebars_widgets" looks like
(which I suppose is some PHPistic anti-readable serialization because why take any clues from those stuffy lispers, we can lern to coad from the back of a cereal box!!)
I'd suggest putting a sequence number in each widget's record so as to sort them, but ofc those are just as bad.
Maybe, but didn't we want to go the opposite direction of letting themes be *just themes* i.e. ~css?
Otherwise, I don't suppose I'd mind this in principle but I don't relish the thought of having to do essentially custom development with reference to mp-wp internals; there would probably have to be a well documented migration process.
Moreover though, there is this notion of "a non-sysadmin given suitable training should be able to administer his blog using a web interface" which wordpress itself was clearly going for and does conceivably make it more marketable especially to organizations. Have you decided whether you want to keep that as a goal? Because if not there's probably a lot more of the admin interface on the chopping block.
Haha, yes! They are indeed awful. Perhaps I should have included a disclaimer: "Description of the current situation != endorsement of the current situation".
The other piece, "who is this for and what level of ability/training/work should be expected of them?", is somewhat harder to answer. I think there are layers to what is considered "custom development" and that some of those may potentially fall within the (suitably trained) HR girl's set of responsibilities in keeping her organization's blog up to date.
1) Editing HTML in blog posts (after all the WYSIWG MS-Word-like editor was removed a long time ago)
2) Editing only a theme's CSS file (this can be done currently btw, a user is free to treat a theme as "only the CSS" by simply ignoring the rest)
3) Editing a theme's HTML and whatever small bits of PHP are sprinkled in
4) Editing actual mp-wp internals (i.e. the actual code running the thing, not just moving around a few function calls)
So level 1 is clearly something our HR girl will have to learn how to do, if she didn't already learn it in one of her "communications" classes in college.
Level 2 might not be handled by the HR girl, but perhaps that cute graphic design chick who's been taking some online CSS courses. Could level 3 also be handled by this girl? Some of her video lectures also talked about Wordpress Theme Customization Basics, so given an hour and some proper documentation she should be able to proudly show off how she added the "Recent Comments" widget to `theme/sidebar.php` if she has to (she's quite clever after all).
No one will want to go near level 4, even if they have the ability, given what an absolute mess of a codebase it is, so that is very clearly just for the masochistic mp-wp maintainers and whatever paid mercenary an organization might hire if they desperately need something that isn't there. Although, I should mention that one of my goals is to eventually have this not be the case (with regard to the abysmal code quality).
Now, the theme (level 3), is sort of the gray area between 2 and 4. Should it be reduced to only CSS or should it be left as is, giving the operator some control over the markup and PHP? If it's reduced to only CSS, the markup/PHP still have to be stored somewhere as code, so someone wanting to make changes will still be able to. Is this an improvement for the person only wanting to edit CSS? Or can this person simply ignore everything that's not CSS? Maybe the CSS file is exposed as an editable textarea in the web UI to make it easier for this person to ignore the rest?
Leaving aside the question of "does moving a theme's markup outside of the theme folder and calling it something else actually make the theme CSS-only or does it just make it more of a pain to customize" (because then simple markup changes would require a fork), I think what first needs to be decided is whether mp-wp is only a blog application, or if it's a "web-displaying application". If it's just a blog platform then we could get really strict with the layout/content options. Sidebar widget order? Fuck you. You can toggle them on/off but the order is what we've determined to be the right order. If, on the other hand, mp-wp is the canonical "web-displaying application" then I think you have to give the user full control over the markup and content that is displayed on their www. Which means they'll need to edit HTML and some light bits of PHP.
I personally see value in both: a rigidly prescriptive blogging application with limited amounts of customizability AND a powerful, fully customizable, displaying-text-on-the-web tool. I also think the user looking for the former can be served equally well by the latter if the tool is designed in such a way that cleanly isolates the first use case from the second.
Finally, going all the way back to the issue of controlling the sidebar widgets (including their ordering) without the need to edit `theme/sidebar.php` and without the use of JS in the web UI, I can think of only three (all pretty bad/silly) options outside of the current unpleasant workarounds:
1) Adding and exposing in the web UI an "order index" field (as you suggested and noted was almost as bad as the current state)
2) Allowing the user to define their widgets with JSON, YAML, or some other data/markup language. The "Widgets" page becomes just a single editable textarea along with some documentation listing the available widgets and their respective options, as well as an example configuration.
3) Adding some up/down buttons in the active widgets list that allow a user to order them one click at a time with a page refresh in between each click
Or the order is permanently fixed and if you want a different order you must then edit `theme/sidebar.php`. Or the "Widgets" page is converted to nothing but static documentation listing the available widgets, their respective options, and copy/pastable PHP snippets for inserting into `theme/sidebar.php`. This would be my personal preference.
She will; mpwp does already help with the line and paragraph breaks and I don't see any conceivable excuse for being on the internet yet not knowing how to spell "a href".
Heh, we seem to be in very hypothetical territory here.
I meant "css" a bit abstractly; the idea being that common functionality is properly factored out of the themes and they're indeed reduced to something that your graphic design chick can churn out a bunch of and tweak without excessive risk of horribly breaking things.
Actually I would find this a livable workaround and it's possibly the simplest way to go for now. What I meant was just that moving the index field to the per-widget config so as to eliminate sidebars_widgets and properly utilize the table structuring of sql wouldn't do much good on its own because those configs (widget_*) are also in that ...overconstrained serialization format.
I'm not sure I follow the distinction/terms here, even after reading the linked thread. So to me it is indeed "only a blog application" but I'm unsure what that implies to you. Note for instance that deploying the IRC logger required thus far precisely zero change to mpwp (and only highlighted the existing brokenness of pingbacks and dumping multiple full articles in single views that ought to be title-only indexes.
The data language you're looking for in this case is clearly SQL. :D
Otherwise and where arbitrarily nested tree structure is actually required, I'm naturally partial to Scheme-flavored S-expressions, but would take JSON in preference to YAML; nobody but Rubyists use the latter as far as I've seen.
That would work for my present needs too, although the initial sidebar.php at least in the classic theme is well into your Level 4, archaeological-layers-of-gnarl code, albeit small by mass.
In that case I think we're fully in agreement, and that's a good way of putting it. It states the end goal clearly ("something that your graphic design chick can churn out a bunch of and tweak without excessive risk of horribly breaking things") but leaves some leeway in determining the solution, depending on how the terms "tweak" and "excessive risk" are defined—which I think is a good thing.
I'm certainly not opposed to this, it doesn't hurt to have this even if more adventurous operators choose to just edit `sidebar.php`.
That all sounds good to me, and maybe we don't need it after all and can decide later when we do.
Agree, and this goes with your first point that themes should allow for the graphic designer to make customizations while minimizing the risk of breaking things too badly. I think abstracting away the gnarly code and leaving behind only clean/intuitive snippets of PHP will result in a successful implementation of the intended goal of "themes".
To me what's meant by "web-displaying application" is something more akin to a "CMS" (which is more or less how fiat-wp positions itself AND what mp-wp already is). So if you have some text/images and want to display/manage them on the web, mp-wp is your tool for doing so. It could be a blog but it could also be a marketing page (like the old pizarroisp.net)—or a log viewer, or a code shelf, etc. If you're dealing strictly with "blog" you can make certain decisions for your user regarding layout, to where the theme really is "only CSS". But if it's a more general purpose "display this text on the web" application then the user needs more freedom to customize the layout, navigation, etc.
Using a concrete example from Pizarro, that top (horizontal) navigation is in the header, which is very easy to do if you can edit `theme/header.php` but would be a pain in the ass to do with only CSS if the nav was permanently stuck in `theme/sidebar.php`. I know you didn't mean "only CSS" (as you explained) but just giving this as an example of a use case handled easily by a "web-displaying application" but somewhat outside the scope of a "blog only" application.
Perhaps - but why would this be more so for a blog than a CMS? That is, I see the distinction you're trying to make but am not convinced that it coincides with the blog-CMS boundary.
To my mind, CMS is the parent concept; thus every blog is a CMS but not every CMS is a blog. What the blog adds is, let's say, the "living" or "engagement" features - feeds, comments, pings etc. In either category the software may be more or less mature, optimized or feature-stabilized. Apache+FTP would constitute a CMS, if a rather basic one.
Back to the concretes and hopefully toward some useful result, I could readily see "blog" being well served by a list of bookmarked / pinned / frequently used pages coming before the article text in the document flow, with less important or historical ones coming after (as in the present "sidebar") or collected under their own page. I'd expect any mature blog would have at least a couple of these. So for the marketing site example, this could serve just as well for its top-level navigation, no?
No disagreement here.
I was referring more to purely the rendered layout, rather than how the content is stored in the DB. One user might want some nav items in the header, someone else wants them in the footer, yet someone else wants them arbitrarily divided between the header and sidebar. Moving around the `<div>`s and the snippets of PHP that spit out nav links makes this trivial. Writing CSS that contorts a fixed <html> structure into the desired result is ugly and tedious. So my point was just that themes can't be CSS-only unless mp-wp were to take the Medium(dot)com approach of "here's your layout, deal with it". The theme will have to allow the user to edit the HTML and a handful of (properly abstracted, with rounded edges so they don't hurt themselves) PHP snippets. Based on what you said earlier ("I meant "css" a bit abstractly...") I don't think there's disagreement here either.
To me, "web displaying application" is something that provides enough flexibility that the user can display any type of text/image content they choose (simple blog, flashy marketing page, dedicated log viewer, dedicated blog search engine, dedicated vpatch code shelf, and anything else a user might come up with). I also think mp-wp already achieves this, by allowing users to edit HTML/PHP as well as CSS in the themes. I agree the PHP a "theme designer" needs to be exposed to could be further refined, and making it so that this theme designer can easily customize the sidebar in `sidebar.php` rather than a click-driven web UI seems like a good goal.
[...] http://billymg.com/2020/06/the-mp-wp-weightloss-program-removing-javascript/ << billymg -- The MP-WP Weightloss Program: Removing JavaScript [...]
[...] billymg « The MP-WP Weightloss Program: Removing JavaScript [...]