Sharing gnucash.css between htdocs and mail-search?

Neil Williams linux at codehelp.co.uk
Tue Jan 17 18:20:24 EST 2006


On Tuesday 17 January 2006 10:41 pm, you wrote:
> I assume that HTTP_HOST is the client's http://XXX/ URL name

Yes. You can always check it with that <?php phpinfo(); ?> file we mentioned 
before. HTTP_HOST is the name that the webserver supplies for the current 
connection. Virtual hosts show up the same, including subdomains. Whatever 
you put in the DocumentRoot in apache, basically. The http:// is omitted.

> and 
> not what you'd get from running hostname at the shell, right?

Correct. (I'm not sure there IS a way for PHP to get that name - unless it 
happens to be the name provided by the webserver.)

> > I'll update the links to svn etc at the same time.
>
> Okay.   Cool!

OK, that's done but there are likely to be some rough edges at this stage and 
some pages won't validate fully as the content itself needs to be updated.

The en/menu/menu*.phtml files *should* be correct but they are easily fixed if 
necessary.

> Then we can think about where we want stuff to be.  svn:externals only
> works on directories, not individual files, but if there are directories
> we want shared we can home them in htdocs and share them into mail-search
> via an external link.

If we want the translated menu shared then all those files will need updating 
to use the $home variable. Not that vital, I suppose, the existing 
translations aren't 100% complete.

The next stage is to look at using gettext with php and see if we can't 
generate a POT file to go alongside existing translations. Then we could 
replace the current files with a wider range of languages. (Although handling 
Arabic, Chinese etc. could be a little tricky!)
:-)

> PS: Nice work so far on all this so far!  :)

I've only done the structure - it's time to get the content updated now!
:-))

I'd recommend that anyone modifying the content uses FireFox with the 
WebDeveloper extension - it has a handy Tool option to upload the current 
file to W3C for validation. It saves uploading a broken file or trying to 
save the HTML source to a file and upload that to W3C manually. (each page is 
dynamically generated and using WebDeveloper means you can check the results 
of dynamic pages without resubmitting them.) The pages work with the simplest 
of Apache virtual host setups. Just a server name and document root really.

Note: The pages are now HTML 4.01 Strict, not transitional. No deprecated tags 
will pass validation:
http://www.codehelp.co.uk/html/deprecated.html

Notable pointers are: no bgcolor (use style), every img must have an alt and 
do NOT use tables for layout, only where the data itself is tabular (at which 
point you need <colgroup><col><colgroup>). I've stripped out a few nested 
tables as well - there remain a few that I will replace with CSS borders 
later when I can see how the updated data looks.

As each page has a validation link that becomes active upon upload to the 
site, it's only sensible to make sure they are valid each time!
:-)

I don't see any need to test in multiple browsers, there are no clever CSS 
tricks in use to trip up IE and I'm not expecting any modern browser to have 
any problems with the pages. The pages have a little way to go to be deemed 
"accessible", particularly for text browsers, but I'll work on that later.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060117/0ea2fc77/attachment.bin


More information about the gnucash-devel mailing list