2 thingies after upgrading

Posted: Thu Jul 24, 2008 10:09 am

Ey guys just upgraded to 2.6.00, had some spare time cause im celebrating my vacation atm, hoorayy Cool

1st I have to say that the new upgrade process is very neat! Displays more info and is pretty much automated, especially the IP2Country updates are a real automated treat for the eyes Razz

Great job!

I did notice 2 little things after upgrading.

1. The following little typo is still there;
http://www.ravenphpscripts.com/postp119805.html#119805

warren-the-ape wrote:

"Click here to check if a new version is availible."

Should be (I suppose);

"Click here to check if a new version is available."

Not sure if it was mentioned before or just overlooked by everyone Razz

2. I immediately noticed that the NS administration displays my right block section as well, whats up with that?

Is there a way to remove that? In my case it takes up important space + it slows down the page loading (my shoutbox is in there and a couple of other blocks as well).

Edit:

3. Another typo; Database Maintence > Database Maintenance
in the main menu.

Not sure if it was posted/noticed already?

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

Regarding #1 & #3 - Just overlooked. Thanks for the reminder.

Regarding #2 - Can't replicate. It works fine on all my sites that I maintain. It would seem to be something local. Include a screen shot and we might be able to take a swag at the cause.

Posted: Thu Jul 24, 2008 3:07 pm

Raven wrote:

Regarding #2 - Can't replicate. It works fine on all my sites that I maintain. It would seem to be something local. Include a screen shot and we might be able to take a swag at the cause.

Well i cant put it any simpler than;

- It displays the entire right block section when i open up the NS administration. ( <left> <NS administration <right> instead of the normal <left> <NS administration>)

NS didnt do that with the 2.5.* versions.

Btw, also the maintenance php file includes the same typo; admin.php?op=ABDBMaintence,
not that its critical cause i can understand changing it would cause more trouble than leaving it as it is Wink

A last minor thing is that I dont really understand the new 'welcome' image.
I think its pretty much redundant cause most of us knew/know what NS would do when we installed it Razz

I replaced mine with another img, just a little bit of web 2.0 (i kept the reflections aside) Wink

(I use a black background)

registered · Posted: Thu Jul 24, 2008 3:10 pm

I get the right blocks too, after upgrading to 2.6.0.

Posted: Thu Jul 24, 2008 3:20 pm

I think I am misunderstanding, as if that's anything new killing me

I thought you were saying that you had right blocks (overlaying) within your admin screen but you mean the standard right blocks of your theme outside of the admin screen - correct? If so, I wouldn't have noticed because I use my right blocks with the admin screen. So, I guess we will log this as a feature, er, I mean bug Wink

- Thanks!

Posted: Thu Jul 24, 2008 3:30 pm

Raven wrote:

I think I am misunderstanding, as if that's anything new killing me

You should register it as your personal trademark Laughing

hehe no kidding, i can understand the mix-up especially when you standard use a 3 column lay-out in the administration.

Quote:

but you mean the standard right blocks of your theme outside of the admin screen - correct?

Yep, correct.

My entire administration uses a 2 column lay-out, so it was a bit of.. WTF Shocked

when i opened up the NS admin after the upgrade Razz

registered · Posted: Fri Jul 25, 2008 7:05 am

warren-the-ape, simply do this:

=== OPEN FILE ===

admin\modules\nukesentinel.php

=== FIND CODE ===

$index = 1;
$advanced_editor = 0;
define('INDEX_FILE', TRUE);

=== REPLACE WITH ===

//$index = 1;
$advanced_editor = 0;
//define('INDEX_FILE', TRUE);

=== DONE ===

Not sure why that changed as its always been a two column layout, but its easy to make it like you want it too. Wink

Posted: Fri Jul 25, 2008 7:36 am

Thnx montego that works perfectly Very Happy

But wont it cause any security risks by commenting out those lines?

Posted: Fri Jul 25, 2008 7:50 am

No, no security risks, it just controls if right blocks get displayed or not. Any module can do this, actually.

Posted: Fri Jul 25, 2008 8:45 am

Okay, yep thought so but you'll never know Wink

Posted: Fri Jul 25, 2008 10:06 am

In the beginning was the $index setting, and the $index setting was with themes, and the $index setting was ... oops! Started quoting Scripture killing me

This actually reveals yet another design/code flaw in all the themes. The themes are supposed to be what controls the display of the right blocks.

In the beginning this was done with a simple check of if ($index==1) {//display right blocks}. Later, if (defined('INDEX_FILE')) { was added and eventually the $index was replaced. Upon closer inspection, if (defined('INDEX_FILE')) is NOT the same as if ($index==1) and is actually invalid code.

if (defined('INDEX_FILE')) is only checking for the existence of the INDEX_FILE constant, not the value. So, define('INDEX_FILE', false) AND define('INDEX_FILE', true) will satisfy the logic check if you use if (defined('INDEX_FILE'))!

The correct logic, whether in themes or elsewhere, should be changed to if ((defined('INDEX_FILE') AND INDEX_FILE===true)) OR (isset($index) AND $index===1)) {//show right blocks} else {//hide right blocks}

By correcting the source of the problem then the inclusion of $index=1; and/or define('INDEX_FILE', true); should work as intended. I say should because the admin/modules/????.php scripts have not actually used the logic much, if at all, in the past. That's why this release of NS exposed the logic flaw.

To the RN Team: I will submit this to Mantis and get the themes corrected.

EDIT by Raven: See my next post 2 posts down. NukeSentinel(tm) is misusing the constant and it will be removed. I will close out the Mantis issue.

registered · Posted: Fri Jul 25, 2008 11:48 am

You are correct, but I don't think this is a design flaw. INDEX_FILE is meant as a constant, not a variable... so checking what value it has isn't particularly necessary.

It has always been, from the Patched files, that defining INDEX_FILE would cause the right blocks to show. Removing this definition would remove the right blocks. Each module is free to decide whether to use this or not.

It isn't quite the same usage as $index, but it is applied consistently through the Patched files. It is not expected that multiple scripts would change $index, so INDEX_FILE in this usage is fine.

Posted: Fri Jul 25, 2008 12:09 pm

But since it has a choice of values, either TRUE or FALSE, then your statement about used consistently just supports my statement that it's being used wrong. If it has values then the values need to be checked; not just the presence. It is being used in a way that is not logical in its own context. The usage as a constant just means it can't be changed unless it is reset as a constant.

EDIT: After musing on this, I've concluded it's a matter of documenting the intended usage of the constant. In actuality, NukeSentinel(tm) is misusing it, correct? So rather than commenting it out it should be removed. I'll be sure to let Bob know and we need to be sure to make this usage very clear in the documentation. Thanks!

Posted: Sat Jul 26, 2008 12:02 am

Correct - intended usage is that defining it is equivalent to displaying the right blocks. The actual values don't matter at all. Using "true" just seemed to be a good of logical as using "false".. which is to say, no logical reason at all Smile

Posted: Sat Jul 26, 2008 7:05 am

Whoops hope this thread didnt create extra work for you guys ^^

And thnx for the little history lesson Raven Wink

Posted: Sat Jul 26, 2008 7:18 am

WTA,

No extra work at all Wink

other than exercising the old thought process Smile

. It is/was definitely a valuable discussion with nothing but positives that came out of it. Thanks!

registered · Posted: Sun Jul 27, 2008 12:00 am

warren-the-ape wrote:

Have it with a white background?

Posted: Sun Jul 27, 2008 12:04 am

Raven wrote:

But since it has a choice of values, either TRUE or FALSE, then your statement about used consistently just supports my statement that it's being used wrong. If it has values then the values need to be checked; not just the presence. It is being used in a way that is not logical in its own context. The usage as a constant just means it can't be changed unless it is reset as a constant.

EDIT: After musing on this, I've concluded it's a matter of documenting the intended usage of the constant. In actuality, NukeSentinel(tm) is misusing it, correct? So rather than commenting it out it should be removed. I'll be sure to let Bob know and we need to be sure to make this usage very clear in the documentation. Thanks!

It's intended use is to cause the right side blocks to be shown. I will add a switch in the next version to allow the webmaster to select if they want the right shown.

Posted: Sun Jul 27, 2008 6:09 am

Bob,

I understand. $index=1; always has been clear. The INDEX_FILE usage (in general, not just with NS) is/was unclear. I agree with you as I stated above in my original treatise Laughing

- INDEX_FILE is being used incorrectly as far as general practice the language construct is concerned.

Displaying the right side blocks, using $index, is dependent on the VALUE of $index, not just the EXISTENCE of $index, as we all know: if ($index==1) displays them and any other value suppresses the display. When the constant INDEX_FILE was introduced, from what Evaders has explained, the usage for displaying of the right blocks was/is only dependent on the EXISTENCE of the constant INDEX_FILE and not the VALUE. So, it matters not whether INDEX_FILE is set to TRUE, FALSE, 999, boys, girls, etc. As long as the INDEX_FILE constant is set to anything then the way the logic/usage in nuke now stands, right blocks will show. To me that is a misuse of the CONSTANT and the language construct in general and can/will cause confusion, especially to new users and those coming from other languages. It doesn't matter, to me, if that's how it's always been. Intuitively and by intended design, if a variable/constant can have a Boolean value of TRUE then logically it can have a value of FALSE. And therefore it should have 2 different RESULT actions. So, by having define('INDEX_FILE',true); in a script to add the right blocks misleads the user to misassume that define('INDEX_FILE',false); will suppress the blocks, which is how it should be, imo.

And just as an aside, imo, the usage of $index should really be Boolean (true/false)and not (0,1) if INDEX_FILE is BOOLEAN. Here again this demonstrates a general lack of design and accepted practice in usage. Either they both should be used wrongly as in
if (isset($index)) {//display right blocks
if (defined('INDEX_FILE')) {//display right blocks
OR correctly as in
if (isset($index) AND $index===true)
if (defined('INDEX_FILE') AND INDEX_FILE===true)

In closing, I still believe the usage of INDEX_FILE is wrong and should be changed from if (defined('INDEX_FILE')) to if (defined('INDEX_FILE') AND INDEX_FILE===true) and we will probably correct it in v2.40.00 of RavenNuke(tm). But for now we will probably just leave it.

Posted: Sun Jul 27, 2008 6:14 am

BobMarion wrote:

Have it with a white background?

Sure, here's a transparent version;

(120*120)

(120*200, original welcome.png size)

Should work on both white and black and also RavenNuke's blue Wink

Posted: Sun Jul 27, 2008 4:57 pm

warren-the-ape wrote:

BobMarion wrote:

Have it with a white background?

Sure, here's a transparent version;

(120*120)

(120*200, original welcome.png size)

Should work on both white and black and also RavenNuke's blue Wink

you just got a credit line in the CREDITS.txt file for 2.6.01 Wink

Provided you approve of me using it in the upcoming distro of course.

Posted: Sun Jul 27, 2008 5:04 pm

Raven wrote:

if (defined('INDEX_FILE') AND INDEX_FILE===true)

I knew when chatserv added it to the patch that the checks didn't truely check properly for the "state" of it's define. So over time I altered most themes I test with to use the line you give above to check the state, let's say on and off so to speak Smile

Still going to add a switch for it so each person can decide if they want right side blocks or not. Personally I alter every theme I have ever had to make right side blocks always present.

Posted: Sun Jul 27, 2008 5:19 pm

warren-the-ape wrote:

1. The following little typo is still there;
"Click here to check if a new version is availible."

Should be (I suppose);

"Click here to check if a new version is available."

3. Another typo; Database Maintence > Database Maintenance
in the main menu

I thought I posted a reply but I guess I hit preview instead of submit. Had a bit too much happening as of late that my brain is still in TN.

Anywho, as I wanted to say. These defines have been changed several times back and forth. This is due to which english you are using. From this point forward I will only use U.S. english in the language file and I am positive I will make plenty of typos and masslpellllllins. hehehehehe

Of course if this becomes a problem I will then revert to good ole RedNeck english which only I and a few others on the planet understand Wink

BTW, they have been changed for 2.6.01 . The latter having been changed shortly after it caught my eye in the 2.6.00 release.

Posted: Mon Jul 28, 2008 4:00 am

BobMarion wrote:

you just got a credit line in the CREDITS.txt file for 2.6.01 Wink

Provided you approve of me using it in the upcoming distro of course.

Sure

Do you need my real name as well? My current nick is a registered trademark by WB Laughing

I do have to add that the keycard icon comes from an iconset;
http://blog.tpdkdesign.net/2005/11/23/refresh-cl/

and comes with a licence;

Quote:

Terms of use
Theses icons are copyrighted, and for personal use only.
Until now, COMMERCIAL USE is strictly forbidden.

You cannot (non-exhaustive list) :
- Use my icons in commercial website
- Use my icons in a professional website layout
- Sell or distribute those icons

For any other use, such as :
- using in non-commercial website
- using icon in free software under GPL licence
you need my authorization to use them. If you have my permission, you need to credit me in your terms and put a link to my website.
I would not be responsible fo any damage you may encounter while using this product.
For any question or request about the pack, please send me an email to tpdk@tpdkdesign.net.

I could also swap it for the shield instead, if its a problem?

Little offtopic; what was the reason for the change in the banners? I thought those gargoyles were pretty nice and 'sentinel' like.

Lolll about that language story, kinda reminds me of those voice sounds in Worms 2 (hope you know the game) Razz

Posted: Mon Jul 28, 2008 10:00 am

warren-the-ape wrote:

I could also swap it for the shield instead, if its a problem?

Little offtopic; what was the reason for the change in the banners? I thought those gargoyles were pretty nice and 'sentinel' like.

Lolll about that language story, kinda reminds me of those voice sounds in Worms 2 (hope you know the game) Razz

To avoid issues with that "license" I think a public domain shield would be better. And here's the shield:
256x256

or
128x128

Changing the banners was two fold, 1) they used "Sentinel" instead of "NukeSentinel", and 2) they were a few years old and I felt the package needed to be updated. Didn't have time to farm out the creation of new banners then but if your interested here are the smaller shields:
48x48

and
32x32

I liked the gargoyles too. Many users kept the old banners on their sites because they liked them so much as well. If you can make a banner that uses the gargoyles with NukeSentinel(tm) instead of Sentinel(tm) (found it is also trademarked elsewhere) I would love to have them as well.