448191

[quote author=proctk link=topic=101575.msg402121#msg402121 date=1153680368] I use the below code to display the logged in regestered users information [b]but I cannot figure out how to assign the users information to variables that i can set to equal form values.[/b] [/quote] I don't understand the question.

Use [i]mysql_fetch_assoc()[/i] or [i]mysql_fetch_array($result,MYSQL_ASSOC)[/i] To elaborate: [b]mysql_fetch_array [/b] ( resource result [, [u][i]int result_type[/i][/u]] ) [i]result_type[/i] The type of array that is to be fetched. It's a constant and can take the following values: MYSQL_ASSOC, MYSQL_NUM, [u]and the default value of MYSQL_BOTH[/u]. Leaving "result_type" will return values twice; once with numeric, once with associative keys.

To better formulate my question (which is probably nessecary, my bad): What do I and do I not cache on the server in a CMS-context.

Can't say I read the info on the site you linked to (yet), but I think your misunderstanding this thread. For the record, it's about php driven (server-side) caching. [quote author=mainewoods link=topic=94531.msg402110#msg402110 date=1153677773] -If you set caching on your pages, the browser and servers beyond you still make there own decisions whether to actually cache the page or not. [/quote] Not true for server-side caching. Clients (browsers) have their own cache, indenpendantly. I does not in any way influence the caching on the server. On the server part, as long as output buffering is enabled (I don't know of a way a server admin could disable it), I can write the buffer to file or rdms, feed it to a browser if required, and thus cache. [quote author=mainewoods link=topic=94531.msg402110#msg402110 date=1153677773] -pages that end with a '?' and url passed variables are not likely to be cached by clients or servers [/quote] It's as likely to be cached on the server as you want it to be, for the reasons above. Client-side, this is probably true. [quote author=mainewoods link=topic=94531.msg402110#msg402110 date=1153677773] -your best strategy is to cache the graphics that are on the page instead of trying to cache the .php page itself!  Put your rarely changing graphics in a directory by themselves and then use a .htaccess file in that directory to set a long term cache on all the files in that directory. [/quote] Argh. This is not what server-side caching is about. Server-side caching is a way to elude some of the processing nessesary to render a page, thus speeding up the page-generation. I'm already using gzip encoding when available clientside, to reduce the bits to be transferred 'tween client and server. Client-side caching is about reducing the number of bits downloaded by reusing some of those (usually images) already stored. To summarize, you're more than likely confused with client side "cache-control" (HTTP Headers). Which is an interesting subject, I'll read up on that too when I have the time, but it's not what this thread is about.

You don't need regex (although I agree it can be useful). Just use an array of [b]functions to allow [/b] and treat all others as strings. Be careful what functions to allow. Distrust any user input (as always). You can't possibly check for al functions you want to exclude, because: 1) There are a lot. 2) Users won't directly be using the php function, but a function or method you will have to write that produces a specific result in the visitors' browser. You have to be pretty sure about this, it sounds like a lot of work.

Old thread, but I left coding for a while.. Still haven't figured this one out. (or just "bump"  ;))

The problem is not in your query. From the MySQL manual: [quote]CREATE TABLE new_tbl SELECT * FROM orig_tbl;[/quote] Look elsewhere.

Here's an example that uses grouping of pages, useful if you have a lot pages: [code]$page = !isset($_GET['page'])?1:$_GET['page']; printNavLinks(800, 6, 10, $page); function printNavLinks($totalItems, $maxitems, $groupsize, $currpage) { //Get number of pages: $pages = ceil($totalItems / $maxitems); //Divide the pages into groups: $groupnr = 0; for($page=1; $page<$pages; $page++) { //If page is dividable by the groupsize, new group. if($page % $groupsize == 0){ $groupnr++; } $groupArr[$page] = $groupnr; } //Display 'previous page link': if($currpage>1){ echo '<a href=test.php?page='.($currpage-1).'>< Previous </a>'; } $groupToDisplay = $groupArr[$currpage]; //Display pages in this group: foreach($groupArr as $page=>$groupnr) { if($groupnr == $groupToDisplay) { if($page == $currpage){ echo '<strong><a href=test.php?page='.$page.'> ['.$page.'] </a></strong>'; } else { echo '<a href=test.php?page='.$page.'> ['.$page.'] </a>'; } } } //Display 'next page link': if(isset($groupArr[$currpage+1])){ echo '<a href=test.php?page='.($currpage+1).'> Next ></a>'; } } ?>[/code] To fetch from mysql use: [code]'SELECT * FROM table LIMIT '.($currpage-1)*$maxitems.', '.$maxitems[/code]

I still stand by my first post. You did adopt some of it. Colourscheme has improved. Some quick fixes: 1) space on the underside of your contenbox. Maybe use some text (copyright, disclaimer, webmaster-contact link etc) as footer. 2) Make the navinks' boxes equal in width. Reduce space between them. 3) Header: make blue fade just into white, not back into blue. 4) Lose moving text, dump the space that will leave. If your client insists on keeping it, at least make it a little smaller, so it takes up less vertical space. Also change the colour so it's not so intrusive. 5) Reintroduce rounded borders around images. Reintroduce dotted line vertical dividers. 6) Suggested layout: top, left-right: resources / find a tutor bottom, left-right: images-text / featured stories 7) Nobody reads welcome texts. Just check how many proffesional sites use welcome-texts. Just trying to help.

Change the blach header to a white / grey gradient. See if you can use the diagonal stripes in it. Trust me, it'll look a lot better. Bottom corners of content look unfinished. Fix displacement of navlinks on rollover.

The site looks really good. I can only comment one thing about the design you might want to fix: one line too may in what could pass as a footer. Try to summarize the bottom two lines into one. It's only a minor issue, but if you fix it you can say you've got a really professional site. Because it's clean otherwise. Good colourscheme, good blend of navigation and content, nice overall solid look. My compliments. P.S. Keep the white bars. It's a nice detail. Although it doesn't serve any pratical function, I feel you should keep them.

Argh... I like the "why choose us" section (but not where it is), other than that: did you read my first post? I modestly believe you'll find the hints you need to produce a professional design in it.

Your problem is not with the choice of reds. Did you read my post at all? Your text "sticks out" with certain links in both FF and IE.

[b]Funny:[/b] This thread being moved from WS Critique to Freelance to Website Critique. [b]Not Funny:[/b] BillyBob trying to spread trojans and making us look at this hidious website. Overall: [u][b]Not funny.[/b][/u]

Above are good comments. That said, let me just totally ignore them and give you a full review. Some issues might have already been noted. The second design is definitely better than the first, but not professional by a long shot. [b]What's good about it:[/b] - The general feel of the elements. Rounded squares are a good choice for a site with this topic. - The general look of the top logo. - General layout of elements (with some exceptions) [b]What's bad about it:[/b] 1) The colour scheme. 2) The alignment and placing of elements and text. 3) The use of tabs. I don't think I have to explain the points I noted you did right. You probably know it, and are proud of it. You should be. You've got a good starting point here. I'll explain the bad points: why I think they are bad points and what you could do about it. [b]1) Colour scheme[/b] Big spaces of bright blue are often too heavy on the eyes. It definitely doesn't match the orange. It curses. Orange is a good choice however, since orange is a very positive colour. Orange is best matched with white and light gradients. Use outlines where necessary. This will give your site a very light and positive look and feel. Look at www.orange.com to see a real life example of this. [b]2) Alignment of elements and text.[/b] Way off on all fronts. [i]A) [/i] Top logo width should match content-container width. [i]C) [/i] The right two columns of the front page need padding/spacing. [i]D) [/i] The block of "text" showing phone numbers shouldn't be there. It makes the space between logo and content look messy. Try if you can fit it in the right side of the logo. Try to fit it elsewhere (move the top elements around) . Just move it from where it is. Leave out the "last minute call" part, it's not such a critical peace of info that it needs to be in a prominent position. Put the info elsewhere. [i]E) [/i] Use a footer. [i]F) [/i] Use the rounded corners theme more consequently. Round your content container to match your tabs and image containers. [b]3) The use of tabs.[/b]The tabs should be made part of the content-container. The best way to accomplish this: Use the same colour, or a gradient fading into the body for the tabs. Use an outline for the tabs, and use the same line to divide tab from body, except for the active tab. Oh, and don't forget to DROP the moving text thingy. I have to agree it's very annoying and distracting. Hope that helps. EDIT: Looking at http://tutor.populateme.com/2/, I really thing you should drop the tabs. Get back the middle contianer look, it's a lot better. The way the navbar is won't do ofcourse, but you can make it look really good with some simple gradients and vertical dividers. All other points still stand though.

As you might remember (I haven't visited this board in quite a while) I critiqued v1, saying it was very intimidating. I didn't explain myself much, since to me it was obvious. I see now I should explain myself. If I remember your original design correctly, you haven't really changed much. The only difference on the design I can note is that you used a less bright red. While this was part the problem, I don't think your changes have improved the design. One thing that has improved by changing to a lighter red is readability of the text in black. This is a mayor, perhaps the most important point (and perhaps not), but in this case it comes at a price. Forget about text not positioned perfectly, for now, it not your biggest problem. What is? Your colour scheme. You've gone from an unreadable potentionally frightening Ferrari-red blur, to a flat boring "grey of reds". You need to find the correct compromise between them. It does however reveal the real problem with that region on your page: it's too monotone. You are in need of a little variation in colour down there. When dosaged correctly, you can get away with many colours. You want this to stand out (you've made that clear by choosing the bright red), but you need to keep it readable and pleasurable to look at. My suggestion (you might have to fiddle with the idea a bit): use the bright red for a thick border around the boxes, fill the boxes with a gradient or mask. Try to find the colour that doesn't curse with the red (so definitely not the lime green) but keeps the text readable. Change the text colour if needed. About the header and footer. Although there might very well be people who like that type of thing (there are even people who paint their hair this colour  :P), I think the green is a bad choice. Change it to a colour that isn't associated with toxic waste. Choosing the right colour scheme (and design in general- not just web design) is all about psychology and human associations in particular. If you want the viewer to experience disgust, you use doo-brown or toxic waste green. If you want the viewer to feel romantic, you use oak brown and/or rose- and sofa red. If you want them to feel happy or carefree you use orange and/or particular variants of yellow, blue and green. So on so on. Take a minute to see what comes to mind first with yourself when you focus on a specific colour. Overall, you need to work on your ability to choose colours. If I go to http://www.network.phileplanet.com/ I discover that the scrutinizer is not an exception in your work. You can't use blue on a black background, it won’t look good, no matter what variant you use. If you can't see this, you need outside help. The bigger part of the colour scheme on http://www.phileplanet.com/ does look more appealing however, so I guess you're not colour blind and have what it takes to make proper colour choices (I'd reconsider the sea blue however). Assembling a colour scheme can be a time consuming, and to some, tedious task. However it is absolutely necessary to take your time and do it right (even if that means starting over until you're ready to throw you head through a window), if you want a large group of people to have the experience you want them to have. Damn, I keep on rambling... Anyway, goodnight, I hope this was of some use to you.

No-one ever dealt with a similar issue? Hard to believe, since performance is always such a big issue.

I've been reading up on output caching, and after writing a complete caching class, wanting to implement it into my config class, I stumbled on this issue. If I want to use caching in a CMS, I have to store a copy of every possible uri, for every user that visits my site, if I don't want to risk one client getting fed another clients' cache. And even if I do that (which would limit the gain from caching to events where a user requests by the same uri more than once - add a bulk of cache on the server - increase server load because of all that extra writing going on), how does the application know some variable data that affect the presentation of a page (like session data, or post input) hasn't changed? Seems to me caching output is pretty much useless for a CMS. Maybe I can limit the caching to publicly available pages (uri's)... Does that make sense? Let's see, how would we go about that... Here's an idea: 1) I check if any 'post' data is present, or the session variable 'user' is set... 2) If none of the above result to true, I use caching. 3) I'll have to separate the output buffering from caching logic, if I am to keep the capability of compressing output using gzip... What do you guys think? EDIT: How about 'chunked' caching... Were do I find a tutorial for this? Google's letting me down (there's a first)... P.S. I'm damn lucky I always use CtrlA-CtrlC before submitting... Almost had to write everything over... Damn Invision "Power" Board!

It might be a good idea to set up some rules for this experiment, like: 1) Run a minimum of 100 test 2) Provide the averages 3) Provide procentual diffrence (which is the most interesting, because these absolute values are hard to compare) [quote]Option 1 average over 266: 0.0032995652435417 Option 2 average over 266: 0.0041864034824802 Option 1 takes 78.8162% of the time option 2 needs. [/quote] Percentage with double quotes: [!--quoteo--][div class=\'quotetop\']QUOTE[/div][div class=\'quotemain\'][!--quotec--]Option 1 takes 30.2693% of the time option 2 needs. [/quote] EDIT: funny thing: I was running automated tests using: [!--quoteo--][div class=\'quotetop\']QUOTE[/div][div class=\'quotemain\'][!--quotec--]<META HTTP-EQUIV="Refresh" CONTENT="1; url=<?php $_SERVER['PHP_SELF'];?>">[/quote] After 1500 runs it more or less leveled out on 84-88%... Then I dicided to speed things up changing the refresh value to 0.5, then the percentage dropped to 49-52% ???? [img src=\"style_emoticons/[#EMO_DIR#]/unsure.gif\" style=\"vertical-align:middle\" emoid=\":unsure:\" border=\"0\" alt=\"unsure.gif\" /] EDIT2: Found out it matters in which order you run the tests! If I switch the echoing parts, the first option you test is always faster than the second. Nesting php in html does seem slower considered this. With the nesting as option 1, it took about 11% of the time option 2 took. With the nesting as option 2, option 1 took about 7.5% of the time the nesting took.

The biggest diffrence between the two options is caused by your use of double quotes! I replaced all the double quotes with single quotes in your testscript. Result: [code]Option 1 average over 200: 0.003299742937088 Option 2 average over 200: 0.0041548562049866 [/code]

I started a session and replaced the bottom couple of lines by: [code]$_SESSION['option1'][] = $t2-$t1; $_SESSION['option2'][] = $t3-$t2; echo 'Option 1 average over '.count($_SESSION['option1']).':  '.array_sum($_SESSION['option1'])/count($_SESSION['option1']).' <br />'; echo 'Option 2 average over '.count($_SESSION['option2']).':  '.array_sum($_SESSION['option2'])/count($_SESSION['option2']).' <br />';[/code] Result after 200 runs: [!--quoteo--][div class=\'quotetop\']QUOTE[/div][div class=\'quotemain\'][!--quotec--]Option 1 average over 200: 0.0033021557331085 Option 2 average over 200: 0.01090927362442 [/quote] Significant difference in favor of option 1, surprised me a bit...

When you debug, isolate. To test if your [u]session script[/u] worked, I tesed only the php code! So you problem is NOT with the php code. [code]<?php session_start(); if (!session_is_registered('background') ) {     session_register('background');     $_SESSION['background'] = 'background_black';     $background = $_SESSION['background']; } else {     echo $_SESSION['background']; } if (!session_is_registered('color') ) {     session_register('color');     $_SESSION['color'] = 'color_yellow';     $color = $_SESSION['color']; } else {     echo $_SESSION['color']; } if (!session_is_registered('size') ) {     session_register('size');     $_SESSION['size'] = 'size_small';     $size = $_SESSION['size']; } else {     echo $_SESSION['size']; } if (!session_is_registered('font') ) {     session_register('font');     $_SESSION['font'] = 'font_verdana';     $font = $_SESSION['font']; } else {     echo $_SESSION['font']; } ?>[/code] On page refresh, this code echoes: "background_blackcolor_yellowsize_smallfont_verdana" which proves sessions are working fine. Your problem lies elsewhere. [i]P.S.[/i] PHP session can use either 'get '(i.e. "index.php?sessionid=1f3870be274f6c49b3e31a0c6728957f") or a cookie to pass the session id across pages... Having your php.ini set to use cookies when a user has cookies disabled will cause sessions to fail, as php doesn't know which session to use.

Pardon, but I tested your code (though very sloppy and way too long for it's intended pupose) and it works fine over here on IE, FF ánd Opera. I don't see the problem... Maybe you have FF set not to accept any cookies?

Pfffff, this XLST shit is though... [img src=\"style_emoticons/[#EMO_DIR#]/unsure.gif\" style=\"vertical-align:middle\" emoid=\":unsure:\" border=\"0\" alt=\"unsure.gif\" /]

I'ts because you use '/' to explode the dirname. The first '/' represents 'root', so use this: [code]list($root,$home,$account,$public,$visitors) = explode('/', $absolute_path['dirname']);[/code] $root will be empty. You could also trim-off the first slash: [code]list($home,$account,$public,$visitors) = explode('/', substr($absolute_path['dirname'],1,strlen($absolute_path['dirname'])));[/code] But I recommend the first method.