Comments on: A guide to systematically exploring the entrails of MP-WP, illustrated using some weird found in the post editor http://thetarpit.org/2019/a-guide-to-systematically-exploring-the-entrails-of-mp-wp-illustrated-using-some-weird-found-in-the-post-editor "Now I feel like I know less about what that blog is about than I did before." Sat, 18 Apr 2026 09:57:21 +0000 http://thetarpit.org hourly 1 By: The Tar Pit MP-WP theme « The Tar Pit http://thetarpit.org/2019/a-guide-to-systematically-exploring-the-entrails-of-mp-wp-illustrated-using-some-weird-found-in-the-post-editor#comment-136 The Tar Pit MP-WP theme « The Tar Pit Mon, 21 Oct 2019 15:57:52 +0000 http://thetarpit.org/?p=329#comment-136 [...] Long story short, look for wp_recent_posts and get_comments in your MP-WP tree, using the grep -rw method outlined in the exploration tutorial. ↩ [...] [...] Long story short, look for wp_recent_posts and get_comments in your MP-WP tree, using the grep -rw method outlined in the exploration tutorial. ↩ [...]

]]> By: MP-WP V patches: Markdown plugin and The Tar Pit LBS post importer « The Tar Pit http://thetarpit.org/2019/a-guide-to-systematically-exploring-the-entrails-of-mp-wp-illustrated-using-some-weird-found-in-the-post-editor#comment-134 MP-WP V patches: Markdown plugin and The Tar Pit LBS post importer « The Tar Pit Fri, 18 Oct 2019 15:03:05 +0000 http://thetarpit.org/?p=329#comment-134 [...] be used as an illustration of MP-WP hacking -- I'm definitely going to reuse some parts for that CLI post editor I'm planning to get running, and yes, that'll also be a patch on this side of the tree. If nothing [...] [...] be used as an illustration of MP-WP hacking -- I'm definitely going to reuse some parts for that CLI post editor I'm planning to get running, and yes, that'll also be a patch on this side of the tree. If nothing [...]

]]> By: spyked http://thetarpit.org/2019/a-guide-to-systematically-exploring-the-entrails-of-mp-wp-illustrated-using-some-weird-found-in-the-post-editor#comment-133 spyked Wed, 16 Oct 2019 08:22:08 +0000 http://thetarpit.org/?p=329#comment-133 Well, notice how my original «should have really contained "<"» got converted to «should have really contained "<"» when you copy-pasted it? If you look at the page source, it does contain the value you pasted, but the browser transforms it, because that's what it's supposed to do, as per the HTML crapitude. Let's look at this again: the user (by which I mean "I", because no one else seems to have stumbled upon this bad juju) a. types "ampersand lt semicolon" into the editor's text box; b. presses "save draft", upon which c. the browser sends "ampersand lt semicolon" via POST, which d. gets saved ad-litteram in the database by the server, which also e. retrieves it again and sends it back to the browser in a response; then the browser f. takes the response and renders it, and more specifically it g. pre-populates the input field with the content, where all HTML entities are transformed back to "what they mean"; so in particular h. "ampersand lt semicolon" is transformed into "left angular bracket". > write something else Now let's say I have a 2K-word post where a subset of these angular brackets are HTML tags, while another subset are supposed to be displayed as actual brackets, so I'm manually converting the "actual brackets" to HTML entities when passing through the content. If you're suggesting that I should do this conversion each time after I press "save draft", then I'm telling you I've done this when I imported the posts and it's utterly fucking insane. Don't get me wrong, I dislike the in-browser post editor as it is and I have a bullet on my to-do list to write a CLI post editor for MP-WP, but I'd rather have it behave sanely while I'm using it... and the fact that this isn't reproducible on other installs only adds to the weird. Well, notice how my original «should have really contained "<"» got converted to «should have really contained "<"» when you copy-pasted it? If you look at the page source, it does contain the value you pasted, but the browser transforms it, because that's what it's supposed to do, as per the HTML crapitude.

Let's look at this again: the user (by which I mean "I", because no one else seems to have stumbled upon this bad juju) a. types "ampersand lt semicolon" into the editor's text box; b. presses "save draft", upon which c. the browser sends "ampersand lt semicolon" via POST, which d. gets saved ad-litteram in the database by the server, which also e. retrieves it again and sends it back to the browser in a response; then the browser f. takes the response and renders it, and more specifically it g. pre-populates the input field with the content, where all HTML entities are transformed back to "what they mean"; so in particular h. "ampersand lt semicolon" is transformed into "left angular bracket".

> write something else

Now let's say I have a 2K-word post where a subset of these angular brackets are HTML tags, while another subset are supposed to be displayed as actual brackets, so I'm manually converting the "actual brackets" to HTML entities when passing through the content. If you're suggesting that I should do this conversion each time after I press "save draft", then I'm telling you I've done this when I imported the posts and it's utterly fucking insane.

Don't get me wrong, I dislike the in-browser post editor as it is and I have a bullet on my to-do list to write a CLI post editor for MP-WP, but I'd rather have it behave sanely while I'm using it... and the fact that this isn't reproducible on other installs only adds to the weird.

]]> By: Mircea Popescu http://thetarpit.org/2019/a-guide-to-systematically-exploring-the-entrails-of-mp-wp-illustrated-using-some-weird-found-in-the-post-editor#comment-132 Mircea Popescu Tue, 15 Oct 2019 20:28:30 +0000 http://thetarpit.org/?p=329#comment-132 <blockquote>which confirms that the bug is on the display side: the page source should have really contained "&lt;" for the browser to show what we intended it to.</blockquote> This doesn't manage to sound like a bug at all to me ; if you want the browser to show something else, write something else, don't expect it to figure it out for you.

which confirms that the bug is on the display side: the page source should have really contained "&lt;" for the browser to show what we intended it to.

This doesn't manage to sound like a bug at all to me ; if you want the browser to show something else, write something else, don't expect it to figure it out for you.

]]>