WordPress.org

Ready to get started?Download WordPress

Forums

BulletProof Security
[resolved] Minor issue with BulletProof Security Security Log (11 posts)

  1. tomdkat
    Member
    Posted 1 year ago #

    I'm running BulletProof Security .48.2 on WordPress 3.5.1 and it works well! I have no "problems" to report at all. :) The minor issue I'm having with it is with the security log. When, I view the security log, the log information appears ok but the textarea element, where the log information appears, is too wide and spills outside of the main content area of the security log page. This requires me to scroll to the right to access the scrollbar for the textarea element so I can scroll it down to see the logged information. This is in Firefox 20 on Ubuntu 12.10 Linux (64-bit).

    Here is a screen shot:

    http://www.tomdkat.com/images/bulletproof-security-log-issue.png

    I took the liberty of making some tweaks to correct this. :)

    In admin/css/bulletproof-security-admin-blue.css, if you add this style rule:

    #bpsSecLog textarea#newcontentSecLog { width: 100%; height: 450px; }

    right around line #12 of the file (near the #bps-container textarea rule), the width of the textarea in question will fit the main content area, regardless of the browser width (not sure about on mobile devices with small screens). The height property isn't required. Then, you could also remove the "cols" and "rows" HTML attributes from the textarea with id "newcontentSecLog" in admin/options.php if you wanted. :)

    Thanks!

    Peace...

    http://wordpress.org/extend/plugins/bulletproof-security/

  2. AITpro
    Member
    Plugin Author

    Posted 1 year ago #

    I will test these changes with all other Browsers and if they work with all other Browsers then these changes will be added permanently. Thanks for pointing this out.

  3. tomdkat
    Member
    Posted 1 year ago #

    Sounds like a plan! Have a great weekend!

    Peace...

  4. AITpro
    Member
    Plugin Author

    Posted 1 year ago #

    I have tested on Firefox 20 and Windows 7 and this issue/problem is not occurring so either it is related specifically to Ubuntu or something else.

    cols="130" rows="27" defines the width and height of the editing window correctly in IE, Chrome, Firefox, Safari and Opera.

    With that said adding this style width to the editing form should force the width when the cols and rows attributes are not recognized so I have added this style inline to the editing form.

    <textarea cols="130" rows="27" name="newcontentSecLog" id="newcontentSecLog" tabindex="1" style="width:675px;"></textarea>

  5. tomdkat
    Member
    Posted 1 year ago #

    What screen resolution are you running? Did you try it with the browser window maximized? I'm running at 1280x1024 resolution and the screen shot I posted above has a width of 1211px.

    If you're running with your browser window maximized, make the window "windowed" and make the width more narrow to see what happens as the width of the textarea with the log info remains fixed while the width of the main content area gets more narrow.

    Peace...

  6. AITpro
    Member
    Plugin Author

    Posted 1 year ago #

    BPS is styled for standard resolutions: 1040 to 1600 and above and displays fine in this range in all the popular Browsers. Anything lower than 1040 is not within standard monitor resolutions and is not factored in as it is outside standard resolutions. 1280 is within that range.

  7. AITpro
    Member
    Plugin Author

    Posted 1 year ago #

    And yes the desired window size is fixed. I intentionally do not want it to scale to 100% so that will not change. If someone reduces their viewing area below 700px then scrolling is the desired/planned result.

    Anything under 700px is a mess and you cannot see the editing window in a way that it is still of value.

    The editing window has a resizing handle so that you can drag and resize it.

  8. tomdkat
    Member
    Posted 1 year ago #

    Thanks for the replies. Well, I found what the problem was. :) It was the font used. In Firefox 20 on Ubuntu, the default "sans-serif" font is "sans-serif". In Firefox 20 on Windows 7, the default "sans-serif" font is Arial. So, when I changed the default "sans-serif" font in Firefox on Ubuntu, the overlap of the textarea in question went away.

    I tried adding your inline-style rule of setting the width at 675px and that addressed the problem as well, regardless of the default "sans-serif" font. Replacing the inline-style of 675px with 100% causes the textarea to fill the width of the main content area and eliminates a lot of word-wrapping of the log data.

    Here's a question I have for you: is the textarea where the log information is displayed intended to be an editable field? If so, why would anyone make changes to the data being displayed?

    Thanks!

    Peace...

  9. AITpro
    Member
    Plugin Author

    Posted 1 year ago #

    Wow wierd one. Ok well in your case then only 100% will work i guess. I will not be changing that to 100% because it is not the way I want the text area to display. I do not want it to display all the way across the window by default. The resizing handles allow someone to choose to do that if they want to do that.

    Yes, it is intended to be editable for simplicity sake to include every possible scenario. I personally cannot think of a reason to edit the file, but someone else probably wants that. By including every possible option I eliminate requests down the road.

  10. tomdkat
    Member
    Posted 1 year ago #

    I can understand not wanting the textarea extending across the browser window in cases where screen resolution is high and the browser window is maxmized. In that case, restricting the width of the main content area is the way to deal with that, since then you control how all of the content is displayed. :)

    "By including every possible option I eliminate requests down the road. "

    The thing is, you're NOT including every possibly option... ;) lol just kidding.

    This isn't a big deal and I can cope with the unnecessarily scrolling to deal with accessing the scroll bar so I can look at the actual log data (just giving you a hard time :)). Now that I know what the actual issue is, I'm happy. :)

    Peace...

  11. AITpro
    Member
    Plugin Author

    Posted 1 year ago #

    The text window is editable and resizable. I set the default size to the best size based on my many years of design experience with extra options available for folks to make individual choices. In the real world you cannot make everyone happy and can only design in a way that makes the majority of folks happy. Trying to make everyone happy is foolish and frankly is just not possible. ;)

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic

Tags

No tags yet.