Directadmin Docs

General information about skins

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:

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:

"/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:

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/{{lang}}/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:

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:
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:
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:

/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:

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.

Last Updated: