vr8ce

I did not take it as such. I disagree with several of your “notes,” and gave reasons why, but that’s not personal, either.

You use “you” throughout your notes (if “you” were speaking of…). “You” is a *personal* pronoun, and in this case the person was me. And then you replied to my post with those notes. That’s the definition of “answering” someone. I’m not sure why you would try to indicate otherwise, but whatever makes you feel better.

I shared some “notes” correcting some of your erroneous conclusions in your “notes.”

• This reply was modified 6 years, 7 months ago by vr8ce.

1. That’s not really your call. Whether you think it’s desirable or not is immaterial — *I* think it’s desirable, and I’m the user.

2. For Categories/Tags, that’s good. (I only did one post, so I didn’t see that it stuck.)

For excerpt, however, it’s still bad. Where excerpt is currently placed in the standard editor, at the bottom of the post and having a full-width entry box, is vastly preferable to the tiny box on the sidebar. That box only holds twenty 5-character words, which means scrolling, which means hard-to-read. It needs to be moved back to the main window, or re-thought entirely. The sidebar is not a good place for it.

3. No, they don’t. They imply they can be *resized*, which is why they are (again) *universally* used. Every image editor/manipulator defaults to keeping proportions when re-sizing. And therefore, no, the sides do not make more sense, because they are completely non-standard.

6a. The current editor puts *tags* (blockquote, code, etc.). The worst thing it does is put an align style in the p tag, and I’m not a big fan of that, either, but it’s self-contained and obvious.

Gutenberg isn’t doing that (on the example I gave, the background color). It’s inserting (or using) invisible styles and/or CSS. Those aren’t close to the same thing. I repeat; it’s a deal-killer.

6b. And, no, it is not necessarily “their” site. Large numbers of sites have multiple authors, and those authors don’t get to freelance their formatting. The site CSS exists for a reason.

7. I don’t care what it can do with custom post types. I don’t use custom post types. Nor does it address anything I was talking about.

8. You missed the point. The point was no documentation. (Plus your answer doesn’t really address all of my questions, anyway.)

9. You missed this point, too. I don’t want to change the behavior of the *editor*. I want to prevent the editor from changing the look of my *posts*. To stick with the same example I’ve been using, I don’t want colored backgrounds in posts on my sites. I don’t want any author to be able to create them. Again, the site’s CSS exists for a reason, because that’s the way the site should be formatted. I want the editor to respect that. (And I mentioned a way to get around your “big ask”. That was off the top of my head. I’m sure the WP team could come up with another half-dozen better ways to do it. The point is it should be done by *respecting the site’s CSS*.)

And thanks, but no, I’ll stick with my own MD editor. What type of Markdown is Gutenberg using? (Standard, Multi, Github, Common, etc.) What revision of whichever one of those is it using? How does it handle footnotes? Superscripts? Feature X? (Again, no documentation.) Why would I jack around with what Gutenberg may or may not be doing instead of going with I *know* my editor is doing? No reason whatsoever.

Thanks, Steve. I finally had some time to play with this today. Here’s what I did for anyone searching for a similar solution.

function filter_recent_posts($args) {
    $args = array(
        'post_type' => 'post',
        'tax_query' => array(
            array(
                'taxonomy' => 'post_format',
                'field'    => 'slug',
                'terms'    => array( 'post-format-aside' ),
                'operator' => 'NOT IN',
            ),
        ),
    );
    return $args;
}
add_filter('widget_posts_args', 'filter_recent_posts');

Thanks for the quick reply!

Too many unnecessary options = not good. Agreed.
However, with sane defaults, the user *doesn’t* have to make a choice. It just works the way they want. But giving an option empowers other users who don’t want that default. This is especially true when the default behavior is out of the mainstream. (Having an <hr> in front of footnotes is a de facto standard in my web viewing, as is the #8617 for the return symbol.)

But, if you don’t want to do that, it’s your plugin. ??

It *might* be possible for me to format the border top as an hr, or get a font character that resembles (or is) #8617, but that’s a lot of work (for me; I’m not a CSS guru), and I’m still modifying one of the plugin files that has to be maintained after an update, just the CSS instead of the PHP. Since it’s far easier (for me) to add an <hr> and the right character to the PHP, then I’ll just do that.

Thanks very much for the tip on the qtip font stuff and especially the link. Those were the parts I hadn’t been able to figure out.

Sorry, I forgot another suggestion. Would you consider making the symbol used as the “return to post” icon configurable as well? I prefer the rounded ↩ rather than squared-off version EF is using. (I’ve actually never seen that one before.) This could be done with an option and putting it directly in the footnoteCopy in easy_footnote_after_content instead of having it in the easynote CSS.

Thanks again!

For others reading this: using <hr> as the label didn’t work. I didn’t really expect it to, but thought I’d check.