Page 1 of 2

Best way to handle web-adminable options

Posted: Wed Dec 28, 2005 4:12 am
by blacksnday
I have been trying to think of the best approach
to offer web-adminable options in any application.
I currently have done so by just having code in the open
(not even in a function)
and determined by a variable, which I know sucks.

Classes arent an option for me just yet,
so what would the advice be when handling this with functions?

Re: Best way to handle web-adminable options

Posted: Wed Dec 28, 2005 5:16 am
by onion2k
blacksnday wrote:I currently have done so by just having code in the open (not even in a function) and determined by a variable, which I know sucks.
What makes you think it sucks?

Posted: Wed Dec 28, 2005 5:27 am
by blacksnday
I am just thinking there has to be a better way.
Mainly for organizational and portable purposes.

Right now I have set up SQL with
name---value
then check it based on what option is chosen.

Below is an example of how I am doing it
with code being by itself and having its own table
this is giving me the option to have random image alt tags:

Code: Select all

$getImageAlt = mysql_query("SELECT * table ORDER BY RAND() LIMIT 1"); 
  while($displayTitle = mysql_fetch_array($getImageAlt))
   { $imgalt = $displayTitle['imgalt']; }
So to use it just have $imgalt inside any image tag on site.
To me, that is just horrible and very limited in what I could
make in regards to web-adminable options.

The next bit is what uses the above sql setup
to determine which template folder to select for template files:

Code: Select all

function vf_news_template() 
{
   global $template;	
    $sql = mysql_query('SELECT value FROM table WHERE name="template"') or die (mysql_error()); 
     while($vfn_template_select = mysql_fetch_array($sql))
    { 
      $template = $vfn_template_select[value]; 
     }  
}
To use this, first the function is called with my file that includes all
other essential files, then when calling a template file
just do it like

Code: Select all

include("templates/$template/header.php");
And just the same, it seems that eventually options would become very
limited as well as just not looking like a proper setup to have for this.

Maybe its just me thinking to much into?

Posted: Thu Dec 29, 2005 10:42 pm
by blacksnday
In regards to my last post, the reason I am having problems
see that being the best way to go about this...

if I have 100 or more adminable options, and all the above code was thrown
into one file for each option then included into main site files
wouldn't that cause performance issues
and then when even more options were created.... and so forth?

Posted: Mon Jan 02, 2006 8:36 am
by BDKR
blacksnday wrote:In regards to my last post, the reason I am having problems
see that being the best way to go about this...

if I have 100 or more adminable options, and all the above code was thrown
into one file for each option then included into main site files
wouldn't that cause performance issues
and then when even more options were created.... and so forth?
So let me get this straight here...

1) For each possible option, you have a file?
2) All of your dynamic setup values are stored in a database?

Posted: Mon Jan 02, 2006 12:28 pm
by blacksnday
BDKR wrote:
blacksnday wrote:In regards to my last post, the reason I am having problems
see that being the best way to go about this...

if I have 100 or more adminable options, and all the above code was thrown
into one file for each option then included into main site files
wouldn't that cause performance issues
and then when even more options were created.... and so forth?
So let me get this straight here...

1) For each possible option, you have a file?
2) All of your dynamic setup values are stored in a database?
umm.....
no
and
no


just close the thread, its not worth discussing anymore
based on what has already been said.
the concern has been lost ....

Posted: Mon Jan 02, 2006 1:15 pm
by John Cartwright
if I have 100 or more adminable options, and all the above code was thrown
into one file for each option
Perhaps rephrasing would not raise so much confusion?

Posted: Mon Jan 02, 2006 1:19 pm
by blacksnday
Jcart wrote:
if I have 100 or more adminable options, and all the above code was thrown
into one file for each option
Perhaps rephrasing would not raise so much confusion?
Common Sense is usually lost admist a world of
politically correct worries.
I see this is no different.

How could one even imagine making 100 files
to hold a few lines of code each that offer the same purpose?

Yet, I have read many discussions and have seen where
people have actually coded that way.

I stand corrected and apologize to all for not spelling it out

Posted: Mon Jan 02, 2006 2:59 pm
by mickd
actually doesnt take that long to make the 100 files if you just make it as you code, not all at once.

although the time taken to make the files in total will still be the same, without the repetition it wont seem as long as it is.

Posted: Mon Jan 09, 2006 3:49 pm
by blacksnday
Today I was updating/adding new code to my current cms project
(well... everyday I do :P )
when I once again started thinking about my question
that started this thread.

I started to form an opinion that some settings would be able
to use Sessions to help ease the load from doing sql queries
on each page load.

So I made my first test case, which is a function to
check for the Admin IP.
Creates a session to store the value of the IP if not yet created.
Once created, as long as that session stays active there would be
no sql queries to constantly duplicate one result:

Code: Select all

function admin_ip()
{
    	if (!$_SESSION['admin_ip']) 
    	{
    $query = @mysql_query('SELECT value FROM table WHERE name="ip"'); 
    while($row = mysql_fetch_array($query))
    { $vfn_admin_ip = $row['value']; }
  			$make_session = $vfn_admin_ip;
			$_SESSION['admin_ip'] = $make_session;
			$admin_ip = $_SESSION['admin_ip'];
		} else {
   			$admin_ip = $_SESSION['admin_ip'];
		}
		
	return $admin_ip;
}

Posted: Tue Jan 10, 2006 4:17 am
by Jenk
you are on the right track as far as validation goes, but the choice of what to validate is not the best choice - namely the IP. Some have dynamic IP addresses, some people use different terminals (I am at work now for example, and also login whilst at home.. that would cause an issue)

Your best bet is to just ask the user to login - then use their login credentials for validation.


Anyway.. I'm not quite sure what you are asking for here.. do you mean you want some options to be restricted to admins.. you have items on a website which are optionally admin'd on a per user descretion basis?

Could you clarify please?

Posted: Tue Jan 10, 2006 5:28 am
by mickd
if you wanted to add abit of security you could for example only allow us ips etc. in my opinion its not needed though.

Posted: Tue Jan 10, 2006 12:57 pm
by pilau
mickd wrote:if you wanted to add abit of security you could for example only allow us ips etc. in my opinion its not needed though.
How do you add only US IPs?

Posted: Tue Jan 10, 2006 3:18 pm
by feyd
there's no way to determine with 100% accuracy if an IP is in the US.. best guess is about as far as you can go, but it takes a bit of time to determine that information.

Posted: Wed Jan 11, 2006 4:32 am
by mickd
i remember reading awhile back somewhere in this forum you could, maybe it wasnt US ips, could of been another country...