FEAT: Integrated Settings Page

[jonathanfinley]

Feature: Integrated Settings Page

STATUS: In development

Current Branch: ALPHA

Progress:

• [x] (Pending) Development
• [X] (Pending) Functionality
• [X] (Pending) Pushed to Alpha
• [ ] (Pending) Test: Windows
• [ ] (Pending) Test: Docker
• [ ] (Pending) Test: Linux
• [ ] (Pending) UI Android
• [ ] (Pending) UI iOS:
• [ ] (Pending) Merged to DEV
• [ ] (Pending) Merged with master
• [ ] (Pending) Release published

Individual setting pages:

1. Info:

• [x] PHPInfo
• [x] Update check/execute
• [x] Github link / Docker Hub link / Donate
• [x] Changelog? https://github.com/github-changelog-generator/github-changelog-generator

2. User Preferences:

• [x] Site Title
• [x] Site URL
• [x] Time Standard
• [x] Time Zone
• [x] Update Branch
• [ NA] Language (I think we should remove this unless we can find a solution - SEANVREE) (future update - Rob)
• [x] Custom CSS
• [x] Custom JS

3. Logarr Settings:

• [x] Refresh log
• [x] Refresh config
• [x] Refresh Time
• [x] Auto refresh logs on/off
• [x] Jump on Search
• [x] Default max lines value
• [x] Auto highlight errors on/off

4. Authentication:

• [ ] Datadir
• [ ] Enable/Disable on logs
• [ ] Enable/Disable on settings
• [ ] Enable/Disable registration

5. Logs:

• [x] Ttitle
• [x] Path
• [x] dynamic path (regex)
• [x] Max line limit
• [x] Auto role file size
• [x] Category
• [ ] Custom error terms highlight on load ??

[seanvree]

Test build currently active in "settings" branch. Having issue with PHP fwrite

[seanvree]

workflow moved to top comment.

[rob1998]

@jonfinley @seanvree should I add an option for live searching? So that it searches when something is being typed in the searchbox. Or do we not want it at all? (don't think performance will be very good with a lot of logs/lines....)

[jonathanfinley]

We had initially thought od doing that, but found the performance suffered greatly.

On Jun 4, 2018, at 12:48 PM, Rob Gökemeijer [email protected] wrote:

@jonfinley https://github.com/jonfinley @seanvree https://github.com/seanvree should I add an option for live searching? So that it searches when something is being typed in the searchbox. Or do we not want it at all? (don't think performance will be very good with a lot of logs/lines....)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Monitorr/logarr/issues/17#issuecomment-394422870, or mute the thread https://github.com/notifications/unsubscribe-auth/AWNF3-yv7B_yOcBUMSzwO_8bWO_EScLgks5t5WTNgaJpZM4O5hpe.

[rob1998]

Yep I haven't tested it myself, but I can see how badly performance would suffer. Just wanted to know your opinion 😄

[seanvree]

@rob1998 yeah, you can test it out. I think it will prob produce a memory leak, but you're welcome to try. I would test with a huge ammount of logs...at least 10 logs with at least 3MB each and max limit of above 3000.

[rob1998]

I would do application changelog only. Should be pretty easy to include that in the settings page, once you have it on github

[rob1998]

@seanvree I see you added custom error terms, do you want those to be log specific or general? I think the easiest way to add them is to add a text field. Then separate terms by splitting everytime there's a comma in the string.

[seanvree]

Humm....I would probably say just general. For example, highlight all "Warn" occurrences in yellow, same way we do "error"

[rob1998]

Okay, yeah so also no different colors? Different colors would again require an array, so harder to implement in the settings page All yellow is also good I think

[rob1998]

maybe we can include a class when content is being highlighted, for example warn. That way users can change colors using custom css. I think that's possible. (Just an idea for later)

[seanvree]

well, the best snecario would be something like Term: "error" color: "Red"

[rob1998]

@seanvree yeah, but that would require an array (like the logs configuration), which doesn't look very nice in alpaca

Option 1: I was thinking of a normal text input field where one would enter something like "error,warn,info". Then this string is being parsed by php/JS and every term is highlighted. Then the term is added as a class to each highlighted piece of text and with this you can edit the colors, we can add default classes for above terms (since they would be pretty standard I think)

Option 2: Almost the same, but now with a string like this: "error:red,warn:yellow,info:blue", then the parsing would be a bit harder, but we could make it into an array or something that has the term as key and the color as value for example

Option 3: The alpaca array field, really not a fan of this one. You saw what happened with the disk thingy

[seanvree]

@rob1998 option 3) we wouldn't have do an array if we do it for ALL logs right?

[seanvree]

@rob1998 I"m making notes to the first comment/checklist. Feel free to edit.

[rob1998]

@seanvree bugs:

• jump on search should be functional again, I think?

language: it is possible to implement this, that's why I added it in. I could easily make something for that. But again it's gonna take quite some time to implement it, basically replacing every string we have atm.

functionality:

• if you don't want a certain category you just shouldn't fill it in, when left blank there won't be a link for it. It has no other function than displaying that link atm. Categories are "automatically" created if a "new" one is found in one of the logs data. I see you wanted to add the category to the log container, but I don't know how useful/necessary that would be.
• If you set the log roll size to 0, it won't roll it. So that's a toggle, right?
• Individual updating is something I've been thinking about, I was thinking of saving it for the next release, since it's kind of a big update again and I just wanted to be sure that this all works

style:

• I don't remember atm why I made the links on the login/register page, but they were not only for dev purpose, so I should check that. Register functionality is something we should still discuss, gonna save that discussion for when I'm back. The links might have to do with the register functionality
• I didn't know what to do with the tools option, I put it in, in case I would find something that we could use as tool, but couldn't think of anything.
• I'm still not a fan of the title centered to the container instead of the page, but I guess I could add in my custom CSS again for myself. Be aware: the page title and footer are actually part of the page's html instead of the container html
• logo's: I would say on every place the logo is atm and on the settings page where it says Logarr (above the clock)
• what do you mean that you're not a fan of the log-on container? Just stylewise? Cause I just made the most basic login form I could think of.

[seanvree]

@rob1998

• Jump on search: I'm using chrome, and it always "jumps" despite the setting. Shoot me your site so I can test and make sure it's not just me, also, testing on chrome, or something else?

• Language:
  Are you thinking client-side type of translation which would only translate for that browser session or an actual back-end full-text php-based translation solution? If the latter which library are you thinking? I know this a pretty big job. We can leave it in the UI, just wondering.

• Categories: Yeah, I got the "functionality" of the categories, what I mean is what if you had three categories: 1, 2 & 3, but you wanted to ONLY display cat 1 and 2? That's why I was thinking some type of toggle switch for each category that could be enabled/disabled independently of each other. I actually really liked this, so I did a lot of work on it and got it semi-functional on my site:

The toggle switches are NOT functional, but you can see how it might look. I haven't uploaded the code because I wanted to see what you thought. http://seanvree.com/dev/logarr-settings/ (username : password)

What do you guys think? @jonfinley ?

• Tools option: Yeah I can't think of anything, so unless we need it, let's remove it, and I would say add a "register" nav menu option for that?

• Title center: I mean we took a vote buddy, so I hate to say it, but you might have to do it with your custom CSS. LOL

• Logos: Yeah, I'll take a closer look it's obvious where it will go on the main log page - but as far as the settings pages, I think your right to put it above the clock. (@jonfinley what's your vote on this?)

• Log-on container: I mean, I'm not a fan of the grey container that encapsuates the username and password fields, I prefer the bottom option in the screenshot below:

[rob1998]

@seanvree okay so quick answer (will be researching and fixing stuff you mentioned in the upcoming days):

jump on search: I'll have to check that, might be a bug

language: I was thinking serverside, don't really need a library for it. But I'll look into it further

categories: looks like a good idea, although I would use checkboxes instead of toggles?

tools option: okay

title center: haha yeah I know, I don't really care since I can use custom CSS now :wink:

log-on container: ah okay, that's styling: I'll leave that up to you :wink:

[seanvree]

BUG:

add required extension:

extension=openssl

[seanvree]

BUG add to functions.php:

ini_set('error_reporting', E_ERROR);

[seanvree]

add to PHPinfo.php:

extension check:

• extension=openssl
• write check (https://github.com/Monitorr/Monitorr/issues/200)

[seanvree]

BUG:

fix favicon.png in webmanifest.json

[seanvree]

CHANGE:

• Add test log for default log

[seanvree]

Add:

• BlockUI on settings change

[seanvree]

BUG:

• Add login requirement for all settings pages