DirectAdmin Docs
Search K

Appearance

Skins and Templates ​

Skins are the UI visible to the user when they access the DirectAdmin panel. There are two built-in skins available:

  • Evolution. It is a modern, interactive skin that runs on the user browser and uses a JSON-based API to access DirectAdmin. Evolution has built-in features to change the look and feel of the UI without the need to use a different skin.
  • Enhanced. It is a legacy, static skin based on server-side rendered templates. It has limited customization support.

DirectAdmin supports installing additional 3rd party skins.

A skin can be configured on a per-user basis. This means each user has an associated skin which, will be used for showing UI after the user have logged in.

There is a single login page for not yet logged-in users. The global login page can be customized.

We recommend using Evolution skin and the built-in customization features to make the UI branding.

How to disable a skin ​

If you wish to hide a skin, you can now create a .disabled file in the relevant directory, e.g.,

Disable/Hide a skin:

bash
touch /usr/local/directadmin/data/skins/enhanced/.disabled

where the presence of the .disabled file will cause it to be excluded from the list.

Custom variable in skin.conf ​

You can add a new variable to the skin.conf file, e.g.,

404_override=user/404.html

This setting allows you to control the output of the 404 pages by instead, sending a specific page with the data set in the desired file (e.g., user/404.html, can be changed).

This file is tokenized similar to an HTM_ file.

Note, the FileManager is chrooted, so if you trigger a 404 for a file that does not exist, you'll still get the old format because the 404_override file is loaded after the chroot has already happened.

More options ​

ALL_DOMAINS_SELECT=clean

Causes the domain select that appears on all User Level pages to not have any Javascript, and to have the value:

id='all_domain_select'

allowing actions to be controlled by external Javascript, like Ajax.

TABLES=div

Causes the internal Table class to generate <div> output instead of <tables>.

Translating internal strings: gettext ​

As of DirectAdmin 1.61.1, the binaries will support gettext, for better internationalized string translations.

The path for your language will be at:

bash
"/usr/local/directadmin/data/lang/fr/LC_MESSAGES/internal.po"

DirectAdmin automatically convert the .po to the binary internal.mo version (and update when needed) upon the first load of the internal.po.

The auto-conversion requires the presence of /usr/bin/msgfmt so if you do not have it, install it with:

bash
yum install gettext

Translate ​

  1. To create your internal.po, first take the default which should be found in:

/usr/local/directadmin/data/lang/internal.pot

and copy it to a temporary location for translation.

  1. The translation involves going through each msgid string, and swapping with the correct string for the new given language.

  2. Some msgids will have flag characters such as %s and %d, which are used to place dynamic string/number into. The number and order of these flags must remain intact, else the translation will not work.

  3. Some phrases can be singular or plural. These cases have "msgid_plural" below the msgid. The singular translation goes into msgstr[0] and the plural set beside msgstr[1].

  4. Once you have your translated internal.po file, save it to the path listed at the top of this guide.

Example ​

internal.pot:

#, c-format
msgid " and %d User"
msgid_plural " and %d Users"
msgstr[0] ""
msgstr[1] ""

Say you were to translate this into a french lang/fr/LC_MESSAGES/internal.po, the given result may look like:

#, c-format
msgid " and %d User"
msgid_plural " and %d Users"
msgstr[0] "et %d Utilisateur"
msgstr[1] "et %d Utilisateurs"

where DirectAdmin would internally swap the %d flag with a dynamic number that can change depending on the output.

Updates ​

With each new release of DirectAdmin, there are likely going to be new or changed translations. To add the new translations to your .po file without losing your existing translations, use the command:

bash
msgmerge --update "/usr/local/directadmin/data/lang/fr/LC_MESSAGES/internal.po" /usr/local/directadmin/data/lang/internal.pot

Debugging ​

  1. Check the language of the User fred:
bash
grep "fr" /usr/local/directadmin/data/users/fred/user.conf
  1. Ensure the internal.mo was created, as DA itself needs the .mo from the .po file:
bash
ls -la "/usr/local/directadmin/data/lang/fr/LC_MESSAGES/internal.mo"

If it does not exist, convert it from the .po to see what's going on:

bash
/usr/bin/msgfmt "/usr/local/directadmin/data/lang/fr/LC_MESSAGES/internal.po" -o "/usr/local/directadmin/data/lang/fr/LC_MESSAGES/internal.mo"
chown diradmin:diradmin "/usr/local/directadmin/data/lang/fr/LC_MESSAGES/internal.mo"

Debugging the binaries ​

Ensure that gettext is compiled in:

bash
cd /usr/local/directadmin
./directadmin info

We want to see this in the output:

gettext support: yes
gettext path: /usr/local/directadmin/data/lang

Beyond that, running DirectAdmin in debug mode exactly level 735 will yield information which can be sent to DirectAdmin support for investigation.