For those that hand code...

[n0ctis]

Hi.

What sort of system do you have in place to reduce the amount of
repeat coding you do in a single site when creating new pages?

What do I mean? Well, Dreamweaver etc will keep a template for you I
understand, so if you want a new page in your site just call it up and
add your data. But if hand coding what do *you* do? Design a template,
keep a content free copy I suppose and copy a renamed version then add
the new content. BUT, then you have to update the menus on all of the
already created pages to match. Again and again maybe if the site is
growing.

I suppose the easiest way for that is to cut n paste the menu, but in
my case it will still need tweaking on each page to have the current
page showing by use of the 'name the page body' system. (That doesn't
read right, but work with me.)

Is there an easier system, or is that just it? (Or am I being blind
again?)

I just stuff templates into text files and copy and tweak them as needed.

 

[dorayme]

dorayme wrote:

That is really common. And you would search and replace only those pages
in that section. How would you do that? It looks to me that you would in
effect edit each page individually as you still have to mark the current
page. Or you would need a lot of PHP includes.

This is getting kind of confusing I guess. Using S&R always means
NOT having to actually hand edit each page if you tell the S&R
engine to search and replace over a set of files. So, if you have
a section of the website that has a different kind of menu to the
rest and it is in its own folder, there is not problem. If the
section is not collected together in a folder but there is some
distinguishing feature about the menu on its pages, then again,
there is no problem of the search engine picking only those files
to change as you want. This is a general point independent of how
to manage includes.

But let us suppose that there are includes and you want to make a
copy of your website without includes, a "full-code copy". OK.
You do exactly what I described in the first place. If the php
includes is different to the rest in "only those pages in that
section", then the search engine will only replace those files in
that section. If it is not different, then you have not got a
problem in the first place or else the problem is different.

For example, you might be wanting to make a certain set of pages
have a different menu to the rest. Easy, just grab all those
files and put them into a temporary folder and just let your S&R
engine go to town on that folder. You can get rid of the folder
later.

I'm not saying that's wrong, just curious how you manage a site in the
25 page range. Personally I've found that managing a site that size and
larger requires keeping careful track ...

I use a home server, I use includes. Except for idiosyncratic
personal circumstances to do with a winbox I have to do with
checking IE 6, there is no problem at all. In fact, that is what
includes are all about. Easy management. That is the prime reason
for it. Change the include file and the changes propogate
thoughout the site, just as with external style sheet changes.

 

[dorayme]

It seems to me that many readers here take pride in expending more
effort than is needed. There's a whole thread trashing me when I
suggested using a CMS to maintain a site, everyone preferred to download
the files, edit them, and reupload.

It is true that I do take pride in doing things the hard way
sometimes. But I don't think this is true of my colleagues here.
<g>

There is a curious confusion here? Who would download their
external files for the purpose of editing them? They are not such
unique diamonds that have to brought into the jewellery workshop
to be polished or re-cut every now and then. They are more like
old stock on a shelf that the greengrocer needs to replace with
fresh.

 

[Jeff]

There is very little different between LAMP and WAMP. MySQL login is
one, so I use a bit of PHP (if/else) in my common functions to handle
that.

I don't write much PHP. I find that windows boxes (with perl) are
clueless where the document root is, or for that matter where they are.

Quite common; I use databases with all my sites. I either have a test
suite of data on the development PC, or I backup and load the web
version occasionally. It's no biggie, as I backup the web host data
regularly in any case.

Those ways will of course work, but I would rather test before
deployment.

Well, I guess it depends on how you build a site. If you make a test
page then that isn't really deployed, no one knows the URL. As far as
scripts go, I don't worry about breaking the server. If I did, I suppose
I would test locally, but I don't.

I'm guessing you feel more comfortable working on your own local server.

Download/edit/reupload? Don't you keep a copy of the current source on
your machine?

I always pull off the web in case a colleague has modified the file.
And since almost all files are either database driven (shopping) or CMS,
there is little point in backing them up locally. They weren't created
locally. I suppose if you only work alone, you can have a different set
of rules.

You still have to edit and upload all the files.

What do you do if your host goes belly-up?

Well, I think they are better at IT than myself. I know that I don't
backup every day! I guess I would worry about this if my clients were on
some shaky shared web host, but none of them are.

Jeff

 

[Beauregard T. Shagnasty]

Well, I think they are better at IT than myself. I know that I don't
backup every day! I guess I would worry about this if my clients were
on some shaky shared web host, but none of them are.

I meant belly-up in the sense of bankrupt and 'off the air.' Gone for
good. Could you reconstruct on a new host and have your site
operational within .. a half-day?

 

[Adrienne Boswell]

I meant belly-up in the sense of bankrupt and 'off the air.' Gone for
good. Could you reconstruct on a new host and have your site
operational within .. a half-day?

Here's my configuration:
1. Beta server - test and play
2. Production web server
3. DB server

So, the production server was having some issues and I backed up (FTP)
all the web site files on to the DB server. The next morning, we got
hit with a virus that added malicious javascript to all the HTML and ASP
files. Luckily, I had backed up all those files on the DB server

After I cleaned up the virus, it was simply a matter of uploading the
files from the DB server to the production server. We were back up in
about two hours.

 

[Jeff]

I meant belly-up in the sense of bankrupt and 'off the air.' Gone for
good. Could you reconstruct on a new host and have your site
operational within .. a half-day?

Well, you have a point there. But I'm not at all worried about
RackSpace going under. If they aren't on RackSpace then they are on
dedicated servers that the client owns.

I can move a site to a different server (data, et all) in about 20
minutes (I have to manually create the database, FTP and defaults). I
wrote a couple of utilities for that a month ago when I was transferring
sites from one server to another. I do something similar now for new
sites, transferring from a "library" domain. Sometimes I'll back up data
locally if I don't trust a clients server but in reality I've never had
trouble. Good web hosting these days is pretty good.

I'm more likely to have reliability trouble with my local box than any
server I see. YMMV.

Jeff

 

[Jeff]

Here's my configuration:
1. Beta server - test and play
2. Production web server
3. DB server

So, the production server was having some issues and I backed up (FTP)
all the web site files on to the DB server. The next morning, we got
hit with a virus that added malicious javascript to all the HTML and ASP
files. Luckily, I had backed up all those files on the DB server

Yowza, lucky that you were prepared!

I can root manage a lamp server but I really prefer to put it in
someones hands that really knows their stuff. Sounds like (except for
missing a patch) that you really know your way around a win box. Nice
recovery.

I seem to remember helping someone track a similar problem a few
months back. Nasty bit of encoded js.

Jeff

 

[Mike Barnard]

Hi.

Is there an easier system, or is that just it? (Or am I being blind
again?)

Sorry it's taken me so long to reply to you all. (I hate it when OP's
can't be bothered to reply to those who help them!) Too many good
replies here to answer each individually, but a BIG thank you to each
of you who have bothered to reply. Amazing place this.

What I **NEED** is someone who knows what they are doing to build the
site for me so I can concentrate on learning about Fire Risk
Assessment and start my business. However, as I don't expect someone
to do it for free and I don't have much cash, what I **HAVE** is the
need to learn all the coding stuff too. HTML and CSS is (oddly)
interesting to learn. Now, it looks as if I'll have to learn PHP too.
At this rate I'll be better off starting a job in web design rather
than Fire Assessment! Still, it will be worth it in the long run.
<crosses fingers>

I have google, therefore I have loads of tutorials and illegal copies
of e-books avaiable to me. Lucky me. But which one(s) to choose? I've
already noticed many of them are years old.

I'm going to install Wamp server to see how this stuff all hangs
together. I'm sure there will be lots of pains in the future, but as
this is an HTML group and PHP is off topic I'll annoy someone else for
that!

I'll have lots of other HTML questions soon though, in fact I feel
another thread coming on right now. So don't get lonely; "I'll be
back."

Mike.

 

[Toby A Inkster]

Now, it looks as if I'll have to learn PHP too.

Including a file is as simple as just:

<?php include('filename'); ?>

If that's all you want to do, then that's probably all you'll need to
learn about PHP.

I'm sure there will be lots of pains in the future, but as this is an
HTML group and PHP is off topic I'll annoy someone else for that!

Despite the name of the group, most of us consider anything web-related as
being on-topic in alt.html. People who want a group that keeps strictly to
the topic of HTML should try comp.infosystems.www.authoring.html.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 41 days, 18:47.]

The Semantic Web
http://tobyinkster.co.uk/blog/2008/03/09/sw/

 

[Jonathan N. Little]

Here's my configuration:
1. Beta server - test and play
2. Production web server
3. DB server

Similar setup I have three servers on my LAN. All websites have a local
mirror where I do all my edits and then synchronize with the live sites
online. Local servers are backed up daily rotational disk to disk backup
on another system and one a month archived on DVD media.

Since all my edits are preformed on the local server, I would never
directly edit on the live server, and restore time is how long it takes
to upload the local mirror. Of course, since I am saddled with dialup
can take a bit of time...

 

[Bergamot]

I don't write much PHP. I find that windows boxes (with perl) are
clueless where the document root is, or for that matter where they are.

I've never had that problem. That's what the document root in the Apache
http.conf file is for. Virtual hosts handle different document roots
very well.

If you make a test
page then that isn't really deployed, no one knows the URL.

Ignorance is bliss?

As far as
scripts go, I don't worry about breaking the server.

So what do you do if a change is dependent on things that cannot be put
into production immediately, for example redesigning a particular
feature or function, or even a layout change?

I'm guessing you feel more comfortable working on your own local server.

It's more than that. It's the risk to the client that you run when you
update live files without prior testing. Maybe I have a different
mindset than you, since I was in software development for a long time
before switching to web stuff. Putting untested software into a
production environment is unheard of.

I always pull off the web in case a colleague has modified the file.

You don't use some type of source control system? Even working alone, I
wouldn't want to be without one. It's saved me more than once,
especially recovering something that was lost.

I suppose if you only work alone, you can have a different set
of rules.

If you work in a team, you need a source control system more than if you
work alone.

You still have to edit and upload all the files.

No, you don't. You only have to upload changed files.

What do you do if your host goes belly-up?

Between the sources on my local server and the database backups done by
clients, the full site can be restored elsewhere pretty easily.

 

[Chaddy2222]

I've never had that problem. That's what the document root in the Apache
http.conf file is for. Virtual hosts handle different document roots
very well.


Ignorance is bliss?


So what do you do if a change is dependent on things that cannot be put
into production immediately, for example redesigning a particular
feature or function, or even a layout change?


It's more than that. It's the risk to the client that you run when you
update live files without prior testing. Maybe I have a different
mindset than you, since I was in software development for a long time
before switching to web stuff. Putting untested software into a
production environment is unheard of.


You don't use some type of source control system? Even working alone, I
wouldn't want to be without one. It's saved me more than once,
especially recovering something that was lost.


If you work in a team, you need a source control system more than if you
work alone.


No, you don't. You only have to upload changed files.


Between the sources on my local server and the database backups done by
clients, the full site can be restored elsewhere pretty easily.

That sounds like a good set-up.
I use a system where I upload my sites still in development to a test
directory on the live server (but after reading a number of posts in
this thread ) I am thinking about installing a test server on my WinXP
box as I am thinking that it would make my life a lot easier.

 

[Toby A Inkster]

Luckily, I had backed up all those files on the DB server

A proper disaster recovery plan should not include "luck".

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 41 days, 22:03.]

The Semantic Web
http://tobyinkster.co.uk/blog/2008/03/09/sw/

 

[Jeff]

I've never had that problem. That's what the document root in the Apache
http.conf file is for. Virtual hosts handle different document roots
very well.

Well that may be my problem with windows servers as the ones I see
are running IIS. Thanks, I hadn't really thought about it that way.

Ignorance is bliss?

What does it matter if it is a test page. There's nothing of
importance there.

So what do you do if a change is dependent on things that cannot be put
into production immediately, for example redesigning a particular
feature or function, or even a layout change?

New template, new page and I can publish to a test directory if
needed. I'm assuming those are standard CMS features.

It's more than that. It's the risk to the client that you run when you
update live files without prior testing. Maybe I have a different
mindset than you, since I was in software development for a long time
before switching to web stuff. Putting untested software into a
production environment is unheard of.

I don't see the difference between having the server on your floor or
having it in a data room somewhere. I usually post development software
to a test domain, and I just don't worry about compile time errors.

Now, looking back to all the *real* problems I've had they all had to
do with the production environment and are impossible to find except on
the server they will be deployed to. The last problems I've had have
dealt with email, permissions and token returns from a CC processor
(which requires knowing the path from the submission page). If you test
only on a test server, you never see these.

You don't use some type of source control system? Even working alone, I
wouldn't want to be without one. It's saved me more than once,
especially recovering something that was lost.

My editor auto makes back ups. I'm assuming yours does also? If I was
worried about something I drop it in a backup directory or I save it
with the date embedded before the extension so I know when it dates to.

If you work in a team, you need a source control system more than if you
work alone.

Well, I'll look into this.

No, you don't. You only have to upload changed files.

Well, there's not much point in arguing here. Almost everything I do
is CMS or data related so I would only be updating templates,
stylesheets and defaults files.

Your system relies on you being the only one that touches the files.
OK, for you and your friends that operate the same way I guess.

Jeff

 

[Neredbojias]

A proper disaster recovery plan should not include "luck".

Agreed. Unless, of course, you can't blame someone else.

 

[Chris F.A. Johnson]

Including a file is as simple as just:

<?php include('filename'); ?>

If that's all you want to do, then that's probably all you'll need to
learn about PHP.

And for that, you don't need php, just SSI:

<!--#include virtual="filename" -->

 

[Toby A Inkster]

And for that, you don't need php, just SSI:

<!--#include virtual="filename" -->

This:

<!--#include file="filename" -->

is more efficient. "virtual" spawns an Apache subrequest -- that is,
internally Apache will request a copy of "filename" via HTTP (though it
won't record the request in the log file). "file" simply opens the file
and includes it.

"virtual" is useful when you want to include the output of a CGI script,
but should be avoided for including static files.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 44 days, 16:20.]
[Now Playing: Dave Matthews Band - The Space between]

The Semantic Web
http://tobyinkster.co.uk/blog/2008/03/09/sw/

 

[Chris F.A. Johnson]

This:

<!--#include file="filename" -->

is more efficient. "virtual" spawns an Apache subrequest -- that is,
internally Apache will request a copy of "filename" via HTTP (though it
won't record the request in the log file). "file" simply opens the file
and includes it.

I used to use that, but I have found some (Apache) web servers that
do not support it, and I get [an error occurred while processing
this directive].

Is that a configuration problem?