Website Maintenance
Sometimes something should be improved on our website. This page is intended to collect the right procedure.
Contents
Introduction
www.gnucash.org is the webserver of the GnuCash project. The sources are public available at GitHub. Building is done by a simple GNU Make.
- Branches
- Master: https://www.gnucash.org, the official site,
- Beta: https://www.gnucash.org/beta/ is intended for developing major changes.
Content State
{sizing|develdocs}.phtml are currently (2017) hopeless outdated.
Used Standards
- The static structure is usually written in HTML.
- Html version & encoding
- The main page is based on HTML5 with charset=UTF-8.
- Todo
-
- A few elements like #Metatags contain attributes based on RDFa etc. Some declaration required?
- The dynamic parts are injectet via PHP. You can assume PHP7 is supported.
- Direct formating is disliked. Instead we use the Cascading Style Sheets (CSS) from externals/gnucash.css.
Adding or Changing Text
If you add or change text, keep in mind Gnucash and its website are multilingual. If you - like me and most other people - are not firm in all languages, you should ask the translators, to help you keeping the translations up to date.
"Coding" Style
- Tutorials
- https://www.w3schools.com/ has tutorials for HTML, CSS, and PHP.
The current code is suboptimal. In the future follow standards:
- HTML
- (https://selfhtml.org/ is a good starting point in German)
- PHP
- The PHP Framework Interop Group published them. PSR-0 got obsoleted by PSR-4, so start with PSR-1: Basic Coding Standard.
- A nice tool for modern PHP is PHP-CS-Fixer.
- Multiple occurrences of the same text: Assign it once to a variable and use that.
- Comments
- While are sent to the readers (show source view),
<!-- HTML comments -->
are not visible to them.<?PHP // PHP comment line ?> <?PHP //* and PHP comment block */ ?>
Metatags
Currently 2 sets of metatags are important/partly implemented:
- By Google recognized <meta> tags
- The Open Graph protocol is primary used by Facebook and requires at least the W3C standard Resource Description Framework in Attributes (RDFa).
- Rules
- If applicable,
- put content in a (PHP)
- [global] $variable or
- [define (] CONSTANT […)] and use that in both flavours,
- mark it as T_("Translatable").
- Restrictions
-
- Title
- 60 char,
- Description
- 105 char, first words are today taken as keywords by Google,
- Image
- [TBD: currently slightly too big or because some of
- type, width, length, alt
- are missing]
- Keyword
- Negative impact today as they often were misused.
I18N
- Translatable text is quoted:
- or as single expression in HTML parts
<?php echo T_("A translatable string"); ?>
<?=T_("A translatable string")?>
- Separate data (Numbers, URL, ...) from text:
- Bad
-
<?php echo T_("<span class=\"gnucash\">GnuCash</span> handles internationalized dates and currencies. The application's menus and popups have been translated to 21 languages, including Chinese, Danish, French, German, Hungarian, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Spanish, Swedish, Turkish, Ukrainian, and British English. Documentation is available in English, French, Portuguese and Spanish.");?></p>
- Better
-
<?php printf (T_("<span class=\"gnucash\">GnuCash</span> handles internationalized dates and currencies. The application's menus and popups have been translated to %u languages, including Chinese, Danish, French, German, Hungarian, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Spanish, Swedish, Turkish, Ukrainian, and British English. Documentation is available in English, French, Portuguese and Spanish."), 21);?></p>
- Now an additional translation of the program will not break all website translations.
- Try to avoid putting URLs in translatable strings, but
- links to the wiki should be separate marked translatatable - there might be a translated page in the wiki.
- addresses of images, which contain text should be translatable to link them to localized versions.
- Todo: Try also to avoid Markups in the translatable text.
- Fix me
- Which methods should we use for the images? This needs documentation in Translation, too.
Managing Translations
Moved to Language Administration#Website.
Images
Traditional web icons had a size of 32x32, for today see #Favicon. For other images we have a few tips in Documentation_Update_Instructions#Screenshots_and_Images.
- App icons today have a default size of 48x48.
- Dependencies
- Some images are referenced from elsewhere:
- gnucash: gnucash.appdata.xml
- <screenshots> section
- Wiki_Tips
- [[[:Template:WebURL]]/images/gnucash-perspective.png gnucash-perspective.png]
- [[[:Template:WebURL]]/images/banner5.png banner5.png]
Testing
Spell Check
Ideally you should spell check your textual changes by priority:
- Language: Source files should be in en_US, not en_GB or something else;
- Grammar, including punctuation;
- Typography (Documentation_Update_Instructions#Text_conventions).
- Todo
- Add references and/or tools.
make check
After modifying PHP parts, runmake check
php -l <file>
W3C Validation
There are at least 2 ways to validate pages against W3C standards:
- Local Test
- If PHP and Tidy are installed on your system, you can check your work with HTML Tidy before pushing by e.g.: to test the english version. In theory you should run it for all installed languages as it is possible, that a page is broken only in one language, if the translator made a mistake with the markups in the msgstrings like using uppercase tags in XHTML — or some HTML injection.
clear; LANGUAGE=C php index.phtml | tidy -config tidy.conf # or to locate errors easier: clear; LANGUAGE=C php index.phtml >tmp.html && tidy -config tidy.conf tmp.html # the location is then valid for tmp.html ## Exception: atom.php produces xml (Fixme: There is no authoritative DTD nor XSD for RFC 4287 so xmllint won't work.): clear; LANGUAGE=C php atom.php >tmp.xml && xmllint --valid tmp.xml {-o out.xml|--noout}
- Tip for news
- Because our *news pages are very long, it is suggested to test your new *.news file separatly before the full news page: This 3 warnings are normal because this elements are part of news.phtml. But fix everything else!
$ tidy -config tidy.conf news/200726-4.1.news line 1 column 1 - Warning: missing <!DOCTYPE> declaration line 1 column 1 - Warning: inserting implicit <body> line 1 column 1 - Warning: inserting missing 'title' element Info: Document content looks like HTML5 Tidy found 3 warnings and 0 errors!
- Create an adjusted tidy.conf
- Execute and then adjust it:
tidy -export-config > tidy.conf
- Enabling indentation and wrapping improves the readability. show-filename is only useful, if you do no preprocessing by PHP.
- With Cleanup options you can generate an improved output to be merged back in your files:
- clean: replaces legacy presentational tags: <i>, <b>, <center> when enclosed within appropriate inline tags, and <font>.
- logical-emphasis: replaces <i> with <em> and <b> with <strong>.
- replace-color: replaces numeric values in color attributes with HTML/XHTML color names where defined, e.g. "#ffffff" with "white".
- Final Test
- After pushing and transfer of your changes to the website check the results with https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.gnucash.org%2Fbeta%2Fnews.phtml (vary the last part if you maintained a different page). Fix any errors it reports and re-commit.
The Atom feed can be tested with The W3C Validator.
Mobile Friendliness
Today there are more mobiles than desktop devices.
Metatags
If you changed Metatags and related elements like images, enter the URL at https://metatags.io/ to see how the page would appear in several social media.
Favicon
Because there are in between many flavours of favicons (resolutions, devices, OSes, browsers) you can use a service like
to check and update them.
- Size
- As of 2020-10-05 they recommend 260x260 or more for optimal results and require at least 70x70.
- Type
- As they accept many formats, we recommend PNG.
On Your Localhost
- Todo
-
- Idea
- Set up a web server, usually apache.
- Tip
- Eclipses PHP module can also run a test instance.
- Add your repository to your apache configuration /etc/apache2/conf.d/
- View http://localhost/gnucash/
Future developement
Gettext variants
We are currently using
- PHP-gettext, Copyright (c) 2009 Danilo Segan <danilo@kvota.net>
- Last available version: https://launchpad.net/php-gettext/trunk/1.0.11 released: 2010-12-24
- continued by Seyyed Morteza Moosavi as https://github.com/smmoosavi/php-gettext v1.0.1 28 Oct 2015
And there are:
- https://github.com/php-gettext/Gettext, active, Minimum PHP version supported is 7.2
- https://www.php.net/manual/en/function.gettext since PHP4
User:Fell is not sure, how they relate and to which we should upgrade.
CMS or site generator
There are considerations to modernize the website:
- Full CMS like wordpress or drupal, but monsters to be configured (by Linas) or
- static site generator like https://gohugo.io or https://jekyllrb.com/