Comments on: The MP-WP Weightloss Program: Removing JavaScript http://billymg.com/2020/06/the-mp-wp-weightloss-program-removing-javascript/ Wed, 08 Apr 2026 14:11:25 +0000 http://polimedia.us hourly 1 By: HTML/CSS improvements and a new dark theme for asciilifeform's logotron « billymg http://billymg.com/2020/06/the-mp-wp-weightloss-program-removing-javascript/comment-page-1/#comment-409 HTML/CSS improvements and a new dark theme for asciilifeform's logotron « billymg Tue, 25 May 2021 23:46:00 +0000 http://billymg.com/?p=74#comment-409 [...] billymg « The MP-WP Weightloss Program: Removing JavaScript [...] [...] billymg « The MP-WP Weightloss Program: Removing JavaScript [...]

]]> By: billymg http://billymg.com/2020/06/the-mp-wp-weightloss-program-removing-javascript/comment-page-1/#comment-207 billymg Sun, 20 Dec 2020 17:28:41 +0000 http://billymg.com/?p=74#comment-207 <blockquote>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.</blockquote> No disagreement here. <blockquote>So for the marketing site example, this could serve just as well for its top-level navigation, no?</blockquote> 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.

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.

No disagreement here.

So for the marketing site example, this could serve just as well for its top-level navigation, no?

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.

]]> By: Jacob Welsh http://billymg.com/2020/06/the-mp-wp-weightloss-program-removing-javascript/comment-page-1/#comment-205 Jacob Welsh Wed, 16 Dec 2020 20:04:00 +0000 http://billymg.com/?p=74#comment-205 <blockquote>If you're dealing strictly with "blog" you can make certain decisions for your user regarding layout</blockquote> 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?

If you're dealing strictly with "blog" you can make certain decisions for your user regarding layout

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?

]]> By: billymg http://billymg.com/2020/06/the-mp-wp-weightloss-program-removing-javascript/comment-page-1/#comment-204 billymg Mon, 14 Dec 2020 18:26:10 +0000 http://billymg.com/?p=74#comment-204 <blockquote>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.</blockquote> 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. <blockquote>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</blockquote> 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`. <blockquote>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</blockquote> That all sounds good to me, and maybe we don't need it after all and can decide later when we do. <blockquote>although the initial sidebar.php at least in the classic theme is well into your Level 4, archaeological-layers-of-gnarl code</blockquote> 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". <blockquote>I'm not sure I follow the distinction/terms here, even after reading the linked thread.</blockquote> 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 <a href="http://pizarroisp.net" rel="nofollow">pizarroisp.net</a>)—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.

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.

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.

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

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`.

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

That all sounds good to me, and maybe we don't need it after all and can decide later when we do.

although the initial sidebar.php at least in the classic theme is well into your Level 4, archaeological-layers-of-gnarl code

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".

I'm not sure I follow the distinction/terms here, even after reading the linked thread.

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.

]]> By: Jacob Welsh http://billymg.com/2020/06/the-mp-wp-weightloss-program-removing-javascript/comment-page-1/#comment-203 Jacob Welsh Mon, 14 Dec 2020 07:29:45 +0000 http://billymg.com/?p=74#comment-203 <blockquote>2) Allowing the user to define their widgets with JSON, YAML, or some other data/markup language.</blockquote> 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. <blockquote>copy/pastable PHP snippets for inserting into `theme/sidebar.php`</blockquote> 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.

2) Allowing the user to define their widgets with JSON, YAML, or some other data/markup language.

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.

copy/pastable PHP snippets for inserting into `theme/sidebar.php`

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.

]]> By: Jacob Welsh http://billymg.com/2020/06/the-mp-wp-weightloss-program-removing-javascript/comment-page-1/#comment-202 Jacob Welsh Mon, 14 Dec 2020 07:19:01 +0000 http://billymg.com/?p=74#comment-202 <blockquote>level 1 is clearly something our HR girl will have to learn how to do</blockquote> 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". <blockquote>Some of her video lectures also talked about Wordpress Theme Customization Basics</blockquote> 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. <blockquote>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)</blockquote> 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. <blockquote>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".</blockquote> 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.

level 1 is clearly something our HR girl will have to learn how to do

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".

Some of her video lectures also talked about Wordpress Theme Customization Basics

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.

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)

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 think what first needs to be decided is whether mp-wp is only a blog application, or if it's a "web-displaying application".

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.

]]> By: billymg http://billymg.com/2020/06/the-mp-wp-weightloss-program-removing-javascript/comment-page-1/#comment-201 billymg Sun, 13 Dec 2020 16:58:34 +0000 http://billymg.com/?p=74#comment-201 <blockquote>Those are some dreadful workarounds though, don't you think?</blockquote> 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 <a href="http://billymg.com/2019/03/the-mp-wp-weightloss-program/" rel="nofollow">removed</a> 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 <strong>only</strong> 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 "<a href="http://ossasepia.com/2020/04/27/ossasepia-logs-for-27-Apr-2020/#comment-8312" rel="nofollow">web-displaying application</a>". 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 <strong>if the tool is designed in such a way that cleanly isolates the first use case from the second</strong>. 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 <em>must</em> 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.

Those are some dreadful workarounds though, don't you think?

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.

]]> By: Jacob Welsh http://billymg.com/2020/06/the-mp-wp-weightloss-program-removing-javascript/comment-page-1/#comment-199 Jacob Welsh Fri, 11 Dec 2020 22:30:06 +0000 http://billymg.com/?p=74#comment-199 Those are some dreadful workarounds though, don't you think? I mean, my "sidebars_widgets" looks like <blockquote> a:2:{s:9:"sidebar-1";a:7:{i:0;s:6:"search";i:1;s:5:"pages";i:2;s:15:"recent-comments";i:3;s:12:"recent-posts";i:4;s:5:"links";i:5;s:21:"categories-3716905091";i:6;s:8:"archives";}s:13:"array_version";i:3;} </blockquote> (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. <blockquote>simply editing `theme/sidebar.php`</blockquote> 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. Those are some dreadful workarounds though, don't you think? I mean, my "sidebars_widgets" looks like

a:2:{s:9:"sidebar-1";a:7:{i:0;s:6:"search";i:1;s:5:"pages";i:2;s:15:"recent-comments";i:3;s:12:"recent-posts";i:4;s:5:"links";i:5;s:21:"categories-3716905091";i:6;s:8:"archives";}s:13:"array_version";i:3;}

(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.

simply editing `theme/sidebar.php`

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.

]]> By: billymg http://billymg.com/2020/06/the-mp-wp-weightloss-program-removing-javascript/comment-page-1/#comment-198 billymg Fri, 11 Dec 2020 18:35:28 +0000 http://billymg.com/?p=74#comment-198 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. 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.

]]> By: Jacob Welsh http://billymg.com/2020/06/the-mp-wp-weightloss-program-removing-javascript/comment-page-1/#comment-187 Jacob Welsh Thu, 03 Dec 2020 06:34:43 +0000 http://billymg.com/?p=74#comment-187 Thinking to finally give this a try and I've been <a href="http://fixpoint.welshcomputing.com/2019/misadventures-in-mp-wp-setup-the-sad-work-in-progress-post/#comment-375" rel="nofollow">working</a> 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. 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.

]]>