Hi All,
I have a tiny program:
<!doctype HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>MyTitl e</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1"/>
</head>
<body>
<?php
$host = $_SERVER['HTTP_HOST'];
$server = strtolower($hos t);
echo 'My variables<bg>';
echo("<br>Host: $host");
echo("<br>Serve r: $server");
?>
</body>
</html>
I upload it to my webserver as test.html and as test.php. Then I test
them in my webbrowser. The test.html does not work, but the test.php
does. Can someone tell me why?
Very confused
Lennart Björk
Jan 25 '06
59  7029 
d wrote: That's also exactly why php files should have php as their extensions
- because that's the way that web servers determine which pages not
only need parsing, but which parsing (actually interpretation not
just parsing - hell strict HTML files need parsing!) it needs. Which was my point. It's a side-effect of the limitations of the web
server.
It's not a limitation, it's the design itself. And it's a good design.
Your wanting it to be different (just because you don't like it) shows a
lack of knowledge and perception and thought. To tax a web server with the task of parsing everything that has a
.html extension, when many, perhaps most of them have no PHP in them
whatsoever is just plain stupid.
See how much extra work it gives apache - very little indeed.
I don't agree with that statement at all. Any server serving a lot of
pages is going to be slowed down considerably by parsing pages that need
no parsing. So little, in fact, that you don't even notice it.
I beg to differ. I'm sure there are measurements somewhere. Tell ya
what, since *you* are making the claim then it is incumbent on *you* to
provide the data to prove your assumption. I'll be waiting here but
definitely not holding my breath. Thanks for calling it stupid, though :)
You're welcome! And besides, some web sites have PHP, Perl, jsp, asp and just regular
old cgi stuff. How you gonna mash all of that into just .html files?
Not everyone does that. Of course some websites do that, but not all.
In fact, not even most. Very few will mix all those technologies, or
even subsets of them, on the same server.
Nobody said that one must mix *all* the technologies. In your scheme one
is prevented from even using any two technologies!
BTW: If your ideas here is so intelligent and smart then surely
everybody will want one. Let's us know when you're done coding it! ;-) I don't like that, as the files, when downloaded, are straight HTML.
Well then don't like it all you want however there are good technical
reasons for the way it works and to buck such reasons and configure
your web server in such a way just because you don't like the way
it's done is foolishness.
There are no good technical reasons for it.
Sure there are. Here are two: Speed and Complexity. Also, support of
multiple scripting technologies. There are others. Your sole reason for
wanting it your way: Think having .html makes it look better! Geeze! It's done as a short-cut to allow the server to figure out what is what.
Using certain things to identify file types or even say variable types
in a language itself is exactly how you do things! Next thing you'll be
complaining that having to type <?php ?> is ugly, a short cut and a
limitation! Geeze! I'm saying that figuring out what is what is not always necessary, and
I certainly don't want the presentation of my site to be deteriorated
due to a perceived problem that isn't even a problem :)
Who the hell do you think goes to a web site and sees say .php in the
URL (or .asp, .jsp, .ccf or whatever file extension) and says "Geeze how
unprofessional! The presentation of this site is too deteriorated for me
to look anymore!" (except for deranged people such as yourself)?
--
Ultimate office automation: networked coffee.
d wrote: Hmmmm... That logic doesn't even make sense. You can have a Perl
script or a .exe file that "spits out" just text. Should such files
have a .txt extension?!? The .html signifies that the file contains
HTML - and pretty
much only HTML. A php script contains both HTML and PHP code so
technically speaking it's not just HTML. It only contains HTML when the user gets it. That's my point. The user
is getting a file from your web server, an HTML file, and it has an
extension of something other than HTML.
Hmmm...
jupiter:wget http://defaria.com
--07:50:13-- http://defaria.com/
=> `index.html'
Resolving defaria.com... 192.168.1.103
Connecting to defaria.com|192 .168.1.103|:80. .. connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
[ <=> ] 9,689
--.--K/s
07:50:13 (7.06 MB/s) - `index.html' saved [9689]
Yet the index file on my site is index.php.
So surely you must mean they "get" it with a browser and thus the URL
has a .php at the end of it. Oh horrors! What if the kids see it! You're
sick man! Having your files named due to your servers requirements is a bit
selfish, in my opinion.
Hmmm.... "Doesn't look good" and "selfish". Persuasive arguments indeed!
Would you rather that the server change the URL typed in from .php ->
..html and then be pointing at a file that doesn't exist or is it you
want the server to have to parse each and every file for every thing
known and thus slow down everybody - just so you can see .html instead
of .php? A foolish argument at best. Not to mention it makes websites look terrible.
Oh yes looks horrible - how have we stood for this for so long! It's a
crying shame! Why do you think that browsers shouldn't determine the contents of
the file from it's extension? Truth is it does, multiple times over
in many, many different occasions. Ever hear of mime.types? Ever
actually configure
an Apache server?
Because the RFC says browsers should rely on the content-type header
sent.
Content headers are not always sent. For example, an ftp:// style URL
doesn't send them I believe. There are many other reasons for a
mime.types file. The point (which you missed) was that many things,
processes, applications etc make use of file extensions for the purposes
of determining what type a file is - and rightly so. Of course I have configured apache servers. I don't want to get into a
pissing match here,
Well you started first by pissing and moaning about URLs not having
..html extensions... but please rest assured I've configured some massive apache setups on
some very expensive hardware for some very big clients paying very
good money :) That's all I'll say about that, as it's a vulgar subject
at best.
I hope you weren't configuring them as per your personal likes and
dislikes but instead were configuring them as per the customer
requirements and for speed, etc. Or, if we have properly-coded modules for our web servers.
Define proper! I think they are proper right now. They work as they are
stated to work and they take into account very real world limitations
and constraints and don't waste time on essentially cosmetic crap! We're not hosting things on 386s any more.
Who said we were? Not I! We have gigahertz of power to play with,
Yes so that means we must waste time? You're logic is strange indeed sir. and checking a file for "<?" or "<?php" funnily enough doesn't take a
cluster of supercomputers. It's not rocket science :)
No, implementing an algorithm to do that is not difficult - it's
wasteful. Should the server likewise scan through a 30 Meg mp3 file? A 7
meg bmp file? What if the server find such strings in a <pre> section or
in a .txt file? Lots of considerations that you don't even seem to
acknowledge as you are probably have never designed and written software
before. Again there are very good reasons not to do this and you offer
up only emotional "Well it doesn't look right" reasons which quite
frankly carry very little to 0 weight.
--
Music is the art which is most nigh to tears and memory. - Oscar Wilde
It may be by design, but that doesn't mean it's necessarily good. Surely a dynamic web server should appear exactly the same as a static one - all files that contain HTML when viewed should be called .html. If you want them called any number of things, then be my guest. I just happen to think presentation matters.
As for performance, the numbers are easy to compute. If you know how, say, the PHP apache module works, you'll see that the hit is absolutely, positively minimal. If it was otherwise, the inherent overhead of processing dynamic PHP files would stop people from using PHP on any old webserver.
My scheme doesn't prevent anyone from using more than one technology. It's not as if extensions are the only way of determining what's in a file.
Your points aren't exactly showstoppers. If you're confused by having php in html files, you probably shouldn't be anywhere near a computer in case you look at it funny and choke yourself to death. And as I said earlier, it doesn't stop anyone from using multiple technologies at once, and if a web server struggles because it has to check html files for php when there necessarily isn't any, then it's not going to be very good at running any complex php, as that requires a LOT more work then just checking for "<?php" in a file.
Just because it's the "done thing" doesn't automatically make it the best thing.
If you don't want to take pride in your work and have messy URLs with weird extensions that don't match the content and query strings unreadable to humans stretching from here to the moon, then be my guest.
I'll get back to you with some statistics.
"Andrew DeFaria" <An****@DeFaria .com> wrote in message news:43******** *************** @news.sonic.net ...
d wrote:
That's also exactly why php files should have php as their extensions - because that's the way that web servers determine which pages not only need parsing, but which parsing (actually interpretation not just parsing - hell strict HTML files need parsing!) it needs.
Which was my point. It's a side-effect of the limitations of the web server.
It's not a limitation, it's the design itself. And it's a good design. Your wanting it to be different (just because you don't like it) shows a lack of knowledge and perception and thought.
To tax a web server with the task of parsing everything that has a ..html extension, when many, perhaps most of them have no PHP in them whatsoever is just plain stupid.
See how much extra work it gives apache - very little indeed.
I don't agree with that statement at all. Any server serving a lot of pages is going to be slowed down considerably by parsing pages that need no parsing.
So little, in fact, that you don't even notice it.
I beg to differ. I'm sure there are measurements somewhere. Tell ya what, since you are making the claim then it is incumbent on you to provide the data to prove your assumption. I'll be waiting here but definitely not holding my breath.
Thanks for calling it stupid, though :)
You're welcome!
And besides, some web sites have PHP, Perl, jsp, asp and just regular old cgi stuff. How you gonna mash all of that into just .html files?
Not everyone does that. Of course some websites do that, but not all. In fact, not even most. Very few will mix all those technologies, or even subsets of them, on the same server.
Nobody said that one must mix all the technologies. In your scheme one is prevented from even using any two technologies!
BTW: If your ideas here is so intelligent and smart then surely everybody will want one. Let's us know when you're done coding it! ;-)
I don't like that, as the files, when downloaded, are straight HTML.
Well then don't like it all you want however there are good technical reasons for the way it works and to buck such reasons and configure your web server in such a way just because you don't like the way it's done is foolishness.
There are no good technical reasons for it.
Sure there are. Here are two: Speed and Complexity. Also, support of multiple scripting technologies. There are others. Your sole reason for wanting it your way: Think having .html makes it look better! Geeze!
It's done as a short-cut to allow the server to figure out what is what.
Using certain things to identify file types or even say variable types in a language itself is exactly how you do things! Next thing you'll be complaining that having to type <?php ?> is ugly, a short cut and a limitation! Geeze!
I'm saying that figuring out what is what is not always necessary, and I certainly don't want the presentation of my site to be deteriorated due to a perceived problem that isn't even a problem :)
Who the hell do you think goes to a web site and sees say .php in the URL (or .asp, .jsp, .ccf or whatever file extension) and says "Geeze how unprofessional! The presentation of this site is too deteriorated for me to look anymore!" (except for deranged people such as yourself)?
--
Ultimate office automation: networked coffee.
Here are some tests I did:
I created two virtualhosts in apache. One parses .php files, one parses both .php and .html. I filled it with 150 html documents (from the apache manual), and wrote a script to download each file from each server.
The results:
They're identical. Sometimes the HTML site is faster by 0.002s, sometimes it's slower by the same. So, it's pretty fair to say, that Apache and PHP don't give a damn if they're parsing HTML files for PHP, as as I said, the performance hit is minimal. In fact, there seems to be NO performance hit. In fact, variations of the computer's stress played a far, far greater role in determining the speed of parsing than the apache setup. So, to summarise, whether your PHP module is parsing HTML files with no PHP in them is the least of your worries.
dave.
"Andrew DeFaria" <An****@DeFaria .com> wrote in message news:43******** *************** @news.sonic.net ...
d wrote:
That's also exactly why php files should have php as their extensions - because that's the way that web servers determine which pages not only need parsing, but which parsing (actually interpretation not just parsing - hell strict HTML files need parsing!) it needs.
Which was my point. It's a side-effect of the limitations of the web server.
It's not a limitation, it's the design itself. And it's a good design. Your wanting it to be different (just because you don't like it) shows a lack of knowledge and perception and thought.
To tax a web server with the task of parsing everything that has a ..html extension, when many, perhaps most of them have no PHP in them whatsoever is just plain stupid.
See how much extra work it gives apache - very little indeed.
I don't agree with that statement at all. Any server serving a lot of pages is going to be slowed down considerably by parsing pages that need no parsing.
So little, in fact, that you don't even notice it.
I beg to differ. I'm sure there are measurements somewhere. Tell ya what, since you are making the claim then it is incumbent on you to provide the data to prove your assumption. I'll be waiting here but definitely not holding my breath.
Thanks for calling it stupid, though :)
You're welcome!
And besides, some web sites have PHP, Perl, jsp, asp and just regular old cgi stuff. How you gonna mash all of that into just .html files?
Not everyone does that. Of course some websites do that, but not all. In fact, not even most. Very few will mix all those technologies, or even subsets of them, on the same server.
Nobody said that one must mix all the technologies. In your scheme one is prevented from even using any two technologies!
BTW: If your ideas here is so intelligent and smart then surely everybody will want one. Let's us know when you're done coding it! ;-)
I don't like that, as the files, when downloaded, are straight HTML.
Well then don't like it all you want however there are good technical reasons for the way it works and to buck such reasons and configure your web server in such a way just because you don't like the way it's done is foolishness.
There are no good technical reasons for it.
Sure there are. Here are two: Speed and Complexity. Also, support of multiple scripting technologies. There are others. Your sole reason for wanting it your way: Think having .html makes it look better! Geeze!
It's done as a short-cut to allow the server to figure out what is what.
Using certain things to identify file types or even say variable types in a language itself is exactly how you do things! Next thing you'll be complaining that having to type <?php ?> is ugly, a short cut and a limitation! Geeze!
I'm saying that figuring out what is what is not always necessary, and I certainly don't want the presentation of my site to be deteriorated due to a perceived problem that isn't even a problem :)
Who the hell do you think goes to a web site and sees say .php in the URL (or .asp, .jsp, .ccf or whatever file extension) and says "Geeze how unprofessional! The presentation of this site is too deteriorated for me to look anymore!" (except for deranged people such as yourself)?
--
Ultimate office automation: networked coffee.
Where to begin.
I don't want .php files on the end of my files, because when the user gets them, they don't have any PHP in them. That .PHP is there for my benefit, not theirs, which is unwanted.
FTP requests are not HTTP. When your browser gets files from ftp://, it's not a web browser any more but an FTP client.
I said pissing match, not pissing.
I never said the server should parse MP3 files or whatever, as I'm not generating them dynamically. When I do generate them, I can still have PHP providing them, AND keep the .mp3 as an extension, because of the tools I use on my site. By your logic, if you have a dynamically-generated MP3 on your site, it should end in .php. That's not particularly cool, is it?
My tests have shown, to me at least, that the performance hit is a myth. It's not wasteful. It's a more than reasonable trade-off for having a decent site, with tidy URLs. You wouldn't want your design sloppy, so why your URLs? The site is a whole - asking someone to ignore the mess in the address bar because "it's just the way the web server works" is a bit silly. It's supposed to work for you, not the other way round :)
dave
"Andrew DeFaria" <An****@DeFaria .com> wrote in message news:43******** *************** @news.sonic.net ...
d wrote:
Hmmmm... That logic doesn't even make sense. You can have a Perl script or a .exe file that "spits out" just text. Should such files have a .txt extension?!? The .html signifies that the file contains HTML - and pretty
much only HTML. A php script contains both HTML and PHP code so technically speaking it's not just HTML.
It only contains HTML when the user gets it. That's my point. The user is getting a file from your web server, an HTML file, and it has an extension of something other than HTML.
Hmmm...
jupiter:wget http://defaria.com
--07:50:13-- http://defaria.com/
=> `index.html'
Resolving defaria.com... 192.168.1.103
Connecting to defaria.com|192 .168.1.103|:80. .. connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
[ <=> ] 9,689 --.--K/s
07:50:13 (7.06 MB/s) - `index.html' saved [9689]
Yet the index file on my site is index.php.
So surely you must mean they "get" it with a browser and thus the URL has a .php at the end of it. Oh horrors! What if the kids see it! You're sick man!
Having your files named due to your servers requirements is a bit selfish, in my opinion.
Hmmm.... "Doesn't look good" and "selfish". Persuasive arguments indeed! Would you rather that the server change the URL typed in from ..php -> .html and then be pointing at a file that doesn't exist or is it you want the server to have to parse each and every file for every thing known and thus slow down everybody - just so you can see .html instead of .php? A foolish argument at best.
Not to mention it makes websites look terrible.
Oh yes looks horrible - how have we stood for this for so long! It's a crying shame!
Why do you think that browsers shouldn't determine the contents of the file from it's extension? Truth is it does, multiple times over in many, many different occasions. Ever hear of mime.types? Ever actually configure
an Apache server?
Because the RFC says browsers should rely on the content-type header sent.
Content headers are not always sent. For example, an ftp:// style URL doesn't send them I believe. There are many other reasons for a mime.types file. The point (which you missed) was that many things, processes, applications etc make use of file extensions for the purposes of determining what type a file is - and rightly so.
Of course I have configured apache servers. I don't want to get into a pissing match here,
Well you started first by pissing and moaning about URLs not having ..html extensions...
but please rest assured I've configured some massive apache setups on some very expensive hardware for some very big clients paying very good money :) That's all I'll say about that, as it's a vulgar subject at best.
I hope you weren't configuring them as per your personal likes and dislikes but instead were configuring them as per the customer requirements and for speed, etc.
Or, if we have properly-coded modules for our web servers.
Define proper! I think they are proper right now. They work as they are stated to work and they take into account very real world limitations and constraints and don't waste time on essentially cosmetic crap!
We're not hosting things on 386s any more.
Who said we were? Not I!
We have gigahertz of power to play with,
Yes so that means we must waste time? You're logic is strange indeed sir.
and checking a file for "<?" or "<?php" funnily enough doesn't take a cluster of supercomputers. It's not rocket science :)
No, implementing an algorithm to do that is not difficult - it's wasteful. Should the server likewise scan through a 30 Meg mp3 file? A 7 meg bmp file? What if the server find such strings in a <pre> section or in a .txt file? Lots of considerations that you don't even seem to acknowledge as you are probably have never designed and written software before. Again there are very good reasons not to do this and you offer up only emotional "Well it doesn't look right" reasons which quite frankly carry very little to 0 weight.
--
Music is the art which is most nigh to tears and memory. - Oscar Wilde
>It may be by design, but that doesn't mean it's necessarily good.
I believe it is possible with Apache to explicitly state the type
of each and every page without the use of *any* file extensions.
This gets cumbersome to maintain, though. Some people advocate it
because they want URLs that won't change with web server technology.
I'm not sure that matters for stuff that it's not reasonable to
bookmark or put in a search engine, like the current contents of
your shopping cart, or a page showing a product that will itself
obsolete and no longer be sold much faster than web server technology. Surely a dynamic web server should appear exactly the same as a static
one - all files that contain HTML when viewed should be called .html.
And absolutely *NO* files should be called .htm, ever.
Why? MIME types are the way the server communicates to the browser
what the content is. Not file extensions.
And whether you like it or not, it *is* possible to have a page
that changes its type (as presented to the browser) based on the
results of the query (for instance, if there is a single result,
it's video, if there is not a single result, it's a page full of
choices of videos).
If you want them called any number of things, then be my guest. I just
happen to think presentation matters.
And what do file extensions have to do with presentation?
Gordon L. Burditt
"Gordon Burditt" <go***********@ burditt.org> wrote in message
news:11******** *****@corp.supe rnews.com... It may be by design, but that doesn't mean it's necessarily good.
I believe it is possible with Apache to explicitly state the type
of each and every page without the use of *any* file extensions.
This gets cumbersome to maintain, though. Some people advocate it
because they want URLs that won't change with web server technology.
I'm not sure that matters for stuff that it's not reasonable to
bookmark or put in a search engine, like the current contents of
your shopping cart, or a page showing a product that will itself
obsolete and no longer be sold much faster than web server technology.
Surely a dynamic web server should appear exactly the same as a static
one - all files that contain HTML when viewed should be called .html.
And absolutely *NO* files should be called .htm, ever.
Why? MIME types are the way the server communicates to the browser
what the content is. Not file extensions.
But for human readability, the extension should reflect the content, surely?
And whether you like it or not, it *is* possible to have a page
that changes its type (as presented to the browser) based on the
results of the query (for instance, if there is a single result,
it's video, if there is not a single result, it's a page full of
choices of videos).
That's what Location: headers are for ;)
If you want them called any number of things, then be my guest. I just
happen to think presentation matters.
And what do file extensions have to do with presentation?
The same thing a shop front has to do with a shop's interior :) It's part
of your "client-facing presence", and as such represents your company. I
can understand if other people don't feel like it represents them, but as
something of a stickler for details, it's something I notice.
Gordon L. Burditt
On 26/01/2006 17:43, d wrote: Where to begin.
It would be nice if you started by not top-posting, but I don't think
that's a requirement of this particular group.
I don't want .php files on the end of my files, because when the user
gets them, they don't have any PHP in them.
Given that the average user isn't really aware of what HTML is, I
wouldn't say that that was much of a reason to reconfigure a server in
the way you'd like.
That .PHP is there for my benefit, not theirs, which is unwanted.
If you were really concerned about this, wouldn't the best solution be
to remove 'extensions' from URLs entirely? If you want to relieve the
user of this 'burden', then hiding the mechanics should be the ultimate
goal.
[snip]
My tests have shown, to me at least, that the performance hit is a
myth.
Perhaps, but you haven't actually stated what these tests specifically
entailed so no-one else can perform them and reproduce your results, or
even judge how relevant the tests are to their own circumstances.
[...] It's a more than reasonable trade-off for having a decent site,
with tidy URLs.
A decent site is determined by many things, but URLs have a relatively
low priority (usability and content clearly come first). Length and the
extent to which they can be remembered and transcribed are the most
important factors and 'extensions' don't impact any of these
significantly at all.
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
d wrote: It may be by design, but that doesn't mean it's necessarily good.
In this case it does. Surely a dynamic web server should appear exactly the same as a static
one - all files that contain HTML when viewed should be called .html.
Again, why? Who cares (besides you)? If you want them called any number of things, then be my guest. I
just happen to think presentation matters.
Let's us know when you're done writing your great web server! :-( As for performance, the numbers are easy to compute. If you know how,
say, the PHP apache module works, you'll see that the hit is
absolutely, positively minimal.
A 1/2 cent rise in the sales tax is also minimal - when looked at under
a microscope! However such things raise millions of dollars! If it was otherwise, the inherent overhead of processing dynamic PHP
files would stop people from using PHP on any old webserver.
This argument holds no water whatsoever. PHP files will be processed
with PHP. The issue I was talking about is making each and every file go
through parsing even when no PHP is present. My scheme doesn't prevent anyone from using more than one technology.
It's not as if extensions are the only way of determining what's in a
file.
Then you must make the httpd process overly complicated be having it
have to figure out, each and every time, any of a possibly myriad of
possible web scripting technologies. Your points aren't exactly showstoppers.
And your one point is one of pure aesthetics! If you're confused by having php in html files,
Who ever said that! I'm not stupid! you probably shouldn't be anywhere near a computer in case you look at
it funny and choke yourself to death.
And you're the one getting bent out of shape because a file says .php
instead of .html. Who's confused here? (Hint: You are!) And as I said earlier, it doesn't stop anyone from using multiple
technologies at once,
Yes but it adds unnecessary complications and processing time based on a
whim that only you have! and if a web server struggles because it has to check html files for
php when there necessarily isn't any,
It's not a struggle - it's a waste of time! Do you understand the
definition of the word efficient?!? then it's not going to be very good at running any complex php, as
that requires a LOT more work then just checking for "<?php" in a file.
Again, it's unnecessary work. You can't seem to understand that simple
concept. Just because it's the "done thing" doesn't automatically make it the
best thing.
Again, in this case it does. If not then make your own web server and
see who else in the planet is interested in such "technology ". But don't
quite your day gig! If you don't want to take pride in your work and have messy URLs with
weird extensions that don't match the content and query strings
unreadable to humans stretching from here to the moon, then be my guest.
I measure my work by the quality of the content of the page itself - not
it's URL. To me, and everybody else in the world except apparently you,
I don't find .php as a weird extension (perhaps because I understand it)
nor as any more messier than .html. It's you that have a fetish with
that - not I.
d wrote: Here are some tests I did:
I created two virtualhosts in apache. One parses .php files, one
parses both .php and .html. I filled it with 150 html documents (from
the apache manual), and wrote a script to download each file from each
server.
The results:
They're identical. Sometimes the HTML site is faster by 0.002s,
sometimes it's slower by the same. So, it's pretty fair to say, that
Apache and PHP don't give a damn if they're parsing HTML files for
PHP, as as I said, the performance hit is minimal. In fact, there
seems to be NO performance hit. In fact, variations of the computer's
stress played a far, far greater role in determining the speed of
parsing than the apache setup. So, to summarise, whether your PHP
module is parsing HTML files with no PHP in them is the least of your
worries.
You did a whopping 150 files. Oh my god! How did your poor little server
put up with all that processing???
How many hits does Google get a day? An hour? I don't think they are
even approaching that whopping 150 hits!
BTW: Things deteriorate over time and side of files too as the server
can grow to taking up more and more resources over time. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: saayan |
last post by:
Hi,
I am using PHP 5.0.1 with Apache 2 on Win XP (SP2).
My index.php file has require_once contents.php and also for
functions.php.
My contents.php file also has a require_once for functions.php.
When this code is tested on one machine, it works fine. However on
another machine with identical configuration (same PHP 5.0.1, XP+SP2,
Apache 2), an error message appears :
|
by: bb nicole |
last post by:
Below is my php code which i need to save the jobseeker resume in database. But does not function and show the message: Column count doesn't match value count at row 1 after i add a field name resume_ID as a primary key in phpMyadmin. i dont know what is the error i done. Thanks.
do_resume.php
<?php
include_once("database.php");
class user {
|
by: comp.lang.php |
last post by:
I am using CLI PHP to run a PHP script, c:\wamp\php\php.exe, but
instead of executing my script, it's actually displaying the raw code
instead.
How can I run my code using CLI PHP? I installed WAMP5 on WinXP.
Thanx
Phil
|
by: sandeepifw |
last post by:
plz help
I have a php variable $content on page menu.php
now i wnt to use its value on page menu_items.js
hear menu_items.js create a menubar.its contan both static and dynamic menu
my lase menu as vander is dynamic now how can i use this variable on .js
my js file look like
|
by: priestyuk |
last post by:
Hi everyone: D,
I recently purchased a very smart and ‘expensive’ template from .
You have to install it on your site etc putting in your mysql details, e-mail address, license key etc. So far everything went to plan. Installed perfect. But now it’s running I am getting a list of these messages on my site (www.illuminati-gaming.co.uk):
Brace yourself:
This is a major pain in the back side as its plastered everywhere. Could...
| | |
by: sickboy |
last post by:
Hey everyone,
I am working on a new site, ForceFedTV.com and I have gotten reports that the site runs great on mac, but once loaded on a pc, after clicking a few links then going back to the home button, they claim they get all black and nothing else.
I am working with an index script that incorporates php to create something like frames.
If someone can access the site and maybe even try and speculate on this, that would be great,
...
|
by: Benjamin Grieshaber |
last post by:
Hi,
I´m on SuSE 9.3 with xmlrpc-c and xmlrpc-c-devel installed (ver. 0.9.10)
I tried to compile php with xmlrpc support and got the following errors:
ext/xmlrpc/.libs/xmlrpc-epi-php.o(.text+0x359): In function
`set_zval_xmlrpc_type':
/php-5.2.5/ext/xmlrpc/xmlrpc-epi-php.c:1313: undefined reference to
`XMLRPC_CreateValueDateTime_ISO8601'
|
by: mekalai82 |
last post by:
i have information.php file that file contain following coding <?php
echo phpinfo(); ?>
while i calling the URL ("http://localhost/information.php").
i am getting the coding <?php echo phpinfo(); ?>
not show the php information...... i am new to the php can you help me?
|
by: Patriot89 |
last post by:
I have a quick question in reference to php file extenstions...
I have code for example like this... This is all located on this site www.ixalliance.com/BHS/Default
(This is my nav.php file)
<div class="navstyle" id="navmenu">
<ul>
<li><a href="index.php">Home</a></li>
<li><a href="administration/admin.php" rel="dropmenu1">Administration</a></li>
|
by: Chrisjc |
last post by:
Good afternoon,
I am seeking some php configuration help. Here is the run down I am running Windows server 2003 and IIS V6.0 I have never had issues before until now. I have Symantec Antivirus 11.0 Manager, it controls all the Symantec clients in the company.
Now it uses a web interface for all of its commands and settings which is called (SEPM) This reporting unit uses php, Symantec by default is loading its php.ini from “C:\Program...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| | |
