Settings Screen

[NickGreen]

Synopsis

Which settings should be exposed to the site owner on a custom admin settings screen?

Details

Currently, there are some options which are hardcoded into the plugin. That looks like this:

wp_localize_script(
    'feedland-blogroll',
    'BLOGROLL_OPTIONS',
    array(
    'title'                   => 'Test Blogroll',
    'urlBlogrollOpml'         => 'https://feedland.social/opml?screenname=davewiner&catname=blogroll',
    'urlFeedlandViewBlogroll' => 'https://feedland.social/?username=davewiner&catname=blogroll', 
    'idWhereToAppend'         => 'divBlogrollContainer',
    'maxItemsInBlogroll'      => 40,
    )
);

These type of options are usually exposed on a custom settings screen. The link to that custom settings screen is often placed as a sub-item in the 'settings' menu in wp-admin.

The question(s) are:

• Which of these should be exposed to the site owner to adjust themselves?
• What should these fields be, specifically?
• Should there be any public documentation around filling out these settings?

Side note: for reference, this is what a core settings page looks like (screenshot below)

[scripting]

I have to think about this one a bit, I'll have something in the AM.

And thanks for these excellent questions. I feel like we're covering all the bases.

[scripting]

Good morning @NickGreen! :-)

TL;DR: I came up with the same list as you have with one addition, flDisplayTitle and I didn't include maxItemsInBlogroll.

Here are the details...

My list

This is the list of options I think should be configurable.

1. title
2. flDisplayTitle
3. urlBlogrollOpml
4. urlFeedlandViewBlogroll
5. idWhereToAppend

Comments

I ended up with the same list as you have with two changes,

• add flDisplayTitle, a checkbox that says whether or not you want the title. I'm pretty sure some people will want this. I believe I can make it work, from a layout standpoint, so let's have that option in the UI too.

• remove maxItemsInBlogroll. We can add this later. The problem is this might create an expectation with users that their blogroll isn't worth anything until they have 40 items in it. I want them to feel great even if they only have five. Later, when people have overflowing blogrolls, we can justify that limit. Maybe we'll need it soon -- but they love it when you add features, and you can't take them out without incurring users' (sometimes justified) wrath. ;-)

Caveat

urlBlogrollOpml and urlFeedlandViewBlogroll will be there, but they should be the last options, out of the users's way if they don't know what it means. It's likely we'll have a UI that makes the OPML transparent, so it shouldn't be in their face.

Thinking about this one

We probably also want a place to enter the name of the server we're using as the back-end. It's constant now at feedland.social, but might need to change that, and it's possible for people to run their own FeedLand instances, so it should be possible for users to point their blogroll at other FeedLands. Don't do anything about this yet, I'm still thinking about it.

[scripting]

Also, yes, there will be public docs for all of this.

We're going to go through a process of learning how to guide people through setup and how to create a blogroll in the FeedLand UI.

We're starting off with two close friends, WordPress users, in the concierge service from A8C. I will work with them directly to help get this set up technically and support them in creating and editing their blogrolls.

Then think a bit, write some docs, and maybe create a new simplified UI for creating a blogroll using FL, and then try another couple of users, again close friends and in the concierge loop. Ideally there would be someone from concierge group working with me on this, learning how to do this, and then ultimately writing docs for the concierge people.

With that, perhaps we'll get more users involved, test the docs, see what's what, possibly iterate, and if it all works then, we have a product. ;-)

There's also going to be an interesting question of what the defaults should be for urlBlogrollOpml and urlFeedlandViewBlogroll. The best blogroll I have to offer now is the one I'm using in the demo and on my blog currently.

That would be good enough for the first two testers who are close friends.

[NickGreen]

I've gone ahead and coded a basic settings page as a starting point. Fernando can pick this up this week for further tweaks.

Test settings page URL: http://feedland.blog/wp-admin/options-general.php?page=feedland_blogroll_settings

There are two ways to access the settings page in wp-admin (screenshot):

And the settings page looks like this:

Notes

• It loads the defaults if no settings have been set
• It allows you to set the flDisplayTitle checkbox as either '0' or '1', and passes the value of that to the script, even though the script doesn't currently do anything with that. So in testing, you won't see the title disappear yet until the JS is updated.
• This is designed to be a starting point, so that we have the basics in place, and can be iterated upon.

[fmfernandes]

Hey @scripting, @NickGreen regarding the idWhereToAppend setting:

If we let the user specify a idWhereToAppend, then this would remove all styles from blogroll.css that targets this div, is this intended? i.e. a way for the user to remove all styles and add their own.

[scripting]

@fmfernandes -- this isn't the final design, we will certainly take that setting out of the product before "shipping" -- or supporting for end-users. I just think we might need to be able to change that while we're still figuring this stuff out.

[scripting]

@NickGreen -- @fmfernandes and i had a meeting on server stuff, but did talk a bit about the question of idWhereToAppend

I didn't understand how the plugins are placed, but fernando explained, three times, and now i think i get it.

so we will not need idWhereToAppend to interface.

still to resolve --

1. where is Ubuntu?

2. the styles for blogrollContainer are somehow not making it to the page.

[NickGreen]

@scripting Ubuntu and the styles aren't taking because your styles are applied to a class, but in fact, the div is an id. So For your styles to apply, it should be #divBlogrollContainer instead of .divBlogrollContainer in the css file.

I think that should solve it :)

[scripting]

@NickGreen -- this is the place in the example code where divBlogrollContainer is defined.

<div class="divBlogrollContainer" id="idBlogrollContainer" tabindex="0">
        </div>

In my code, div means class and id means it's an id.

If I changed the CSS it would break my blog and blogroll.social.

[scripting]

On the other hand, there's no harm in having the style also apply to #idBlogrollContainer, so that's what I did.

But -- the blogroll on the test site didn't change. I'm guessing it's all being cached somewhere?

.divBlogrollContainer, #idBlogrollContainer {
    display: table-cell;
    vertical-align: top;
    width: 240px;
    margin-left: auto;
    margin-right: auto;
    margin-right: 10px;
    border: 1px solid gainsboro;
    background-color: white;
    padding-top: 5px;
    padding-bottom: 5px;
    font-family: Ubuntu;
    font-size: 15px;
    }

[fmfernandes]

@scripting, let me take a look at this. I think the plugin is only using id and not class.

[fmfernandes]

@NickGreen, @scripting: Updated the plugin code to use:

<div class="divBlogrollContainer" id="idBlogrollContainer" tabindex="0">

and removed idWhereToAppend from settings/configuration.

Ubuntu and the border is now showing: https://feedland.blog/blogroll-wp-plugin-test/

[NickGreen]

Looks better now, thank you guys. 👍

[scripting]

Thanks @fmfernandes -- we're getting really close. :boom:

I'm going to look at a few things that might need tuning up like line-spacing.

Also is there an easy way to set the background-color on the page to whitesmoke?

It would be helpful for sizing up the before and after comparisons.

[fmfernandes]

Also is there an easy way to set the background-color on the page to whitesmoke?

I've set it to whitesmoke using WP Customizer for only that page.

body.page-id-715 {
  background-color: whitesmoke;
}

[scripting]

I've set it to whitesmoke using WP Customizer for only that page.

thanks.

next question, when I make changes to the CSS (as I just have) how do I get the blogroll on the test page to reflect the changes?

[fmfernandes]

next question, when I make changes to the CSS (as I just have) how do I get the blogroll on the test page to reflect the changes?

Up until now I'm testing doing a hard refresh on Chrome which seems to work well to grab the latest changes. Reloading the page with Command + Shift + R

[scripting]

I've been doing Hard Refresh without getting the changes. I'll try again now that I know it works for you.

I have a CSS puzzle I've been trying to solve, maybe you have an idea.

On the test site, each trBlogrollFeed in the list has a height of 31px. On scripting.com it's 27.5px.

I've been trying to find what accounts for the difference. I think that's the biggest diff now between the two.

Any help much appreciated. ;-)

[NickGreen]

Today, I've created a PR to add the server back onto the settings screen. This is currently what it looks like:

Assuming we want to keep the category off of the settings page, then the davewiner default feed should probably include all of the items that the "blogroll" category previously had.

Another possibility would be to have a different, more generic default user.

@scripting If you have some time to think this through, that would be great.

[scripting]

@NickGreen — I’ll have this for you first thing tomorrow.

[scripting]

Good morning @NickGreen --

I had to get some experience with real users to ground my ideas of how this would work. So I apologize for my confusion, now I feel I have a good picture of how people will understand the instructions.

1. Remove the Display Title option. The blogroll as it's implemented now doesn't work without a title.
2. Every item should have a description underneath it. I've written descriptions for each of the items I want to see in the settings page.
3. Capitalization is important. Things like username and server are not proper names, so should not be capitalized.

With that in mind -- here's the design. The label comes first, the description second. The layout should be as in your screen shot example above.

• Title -- The title appears at the top of the blogroll box. It defaults to My Blogroll.
• FeedLand username -- The username of the account whose blogroll you want shown. (Required)
• FeedLand server -- The server that account is on. (Defaults to feedland.com, required)
• Category (optional) -- You can choose only to have feeds from a specific category in the blogroll, if you want all the feeds you've subscribed to, leave this blank.

We shouldn't wait for the "quiet mode" features to be ready, we're going to need some time to smooth them out. The basic set of features are ready now, imho.

Please let me know if there are any questions, if any of this needs to be better explained.

[NickGreen]

@scripting

Problem

I've hit a small blocker:

This is not returning a feed: https://feedland.com/opml?screenname=davewiner&catname=blogroll

Even though this does: https://feedland.com/?river=true&screenname=davewiner&catname=blogroll

This works with other accounts, but I can't figure out why it's not working for davewiner. This is mostly a problem because this is the new default server and account for the plugin settings.

Any ideas what I'm doing wrong here?

Additional Question

Are we going to have the default category be empty? If so, should we add some more feeds to the davewiner default feed?

[scripting]

The username is required, it does not default to davewiner. If it is not provided that is an error.

I will review the code in blogroll and make sure it calls that an error and does not render a blogroll.

The reason you're not getting anything in the blogroll category for me on feedland.com is that I'm using feedland.social to host my blogroll. I never intended for my account to be used as a default.

However since I mirror my subscriptions at feedland.com it should work, and I'll take a look at why it doesn't. It almost certainly has something to do with the fact that the subscriptions are coming from a reading list subscription. (Actually now that I'm thinking about it, however weird it seems, I think the software is working correctly. We should talk about reading lists at some point.)

[NickGreen]

OK, sounds good. This is how it currently looks: