DirectAdmin v1.640 RC

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
1,081
Hi everyone!

We are happy to announce we have released DirectAdmin 1.640 RC.

With this release we are changing DirectAdmin version structure. We are joining the last two version components making this release a change from 1.63.9 to 1.640. It more closely reflects the release cycles we had for the last ~20 releases. Key change with this release is moving dataskq execution away from cron into the main directadmin web server. Interval for controlling how often dataskq runs is now managed in directadmin.conf field dataskq_run_interval.

Release Change log can can be found here:

DirectAdmin 1.640

The update should be automatically available for all installations subscribed to the beta release channel.

We appreciate all the feedback on forums and issues reported in the ticketing system.

Thanks!
fln
 
Hi

Config value language_list is ignored in this version and all languages (shipped with DA) are listed, own languages (not shipped with DA) are no longer listed and selectable in Evo. Tested on 3 Servers.

Thanks
 
Last edited:
Hi @apogee, regarding the language_list this is a breaking change that we missed in the change log. Mostly because it is not done to the full extent.

The plan is to allow Evolution to keep its own list of supported languages without being controlled from the directadmin.conf effectively deprecating language_list for Evolution. In this release main Evo already has its own language list, but login page still honors the language_list from directadmin.conf. We will discuss this internally with dev team and will either finish it up fully or postpone this change for later releases.

The motivation for this change is to allow Evolution users to use any of the supported languages. I understand it is really tempting to expect that all your users will use a single language (or predefined set of languages). However it is only possible to know for sure if you are the sole user of the server or know all the users personally. Our goal is to expose all Evolution translations but make them quietly optional so that language selection would be there but would not get in your way when using the GUI.

@ARealRiley yes, you can still run dataskq from CLI manually as before. DA web server starts dataskq as a separate unrelated process similar to how the cron service would do. For example restarting DA would not terminate already running dataskq process.
 
Hi fln

it doesn't seem very well thought out to me, especially if the login still takes the option into account and evo itself doesn't. I would like to determine which languages DA offers for us, plus I need to be able to customize the language files because our systems have special features.

What has always bothered me is that EVO has a language package (in /usr/local/directadmin/data/skins/evolution/lang) and DA has its own (in /usr/local/directadmin/data/lang) and you never know which strings are now used by which, this seems to me to be a good plan to unify this.

Now 3 questions:
1. Where are the allowed languages defined for EVO?
2. Where are the po files for EVO (and the dictionaries)?
3. I had to install Alpha on a productive system to fix a bug, how do I get back to 1.639 (is not offered in any release channel), probably via the hash of the last version, but I do not know.

Regarding EVO, another input, with cpanel I can now finally include content with the new jupiter theme, I would like to be able to do this with DA, I cannot imagine that it should be a huge effort to integrate this (create file on the file system which will be included if available in header or foother, as is already the case with the hook system).

Oh yeah one last thing,I noticed that since recently there are question mark links in the titles in EVO which refer to sitehelper documentation, so far so good but this leads us to more support requests. It would be great if we could turn this off or add own link per page to your own documentation (as a config avariable?).

Thanks!
 
Yes, we will restore language_list to work in 1.640 and leave its removal for later releases.

Now 3 questions:
1. Where are the allowed languages defined for EVO?
2. Where are the po files for EVO (and the dictionaries)?
3. I had to install Alpha on a productive system to fix a bug, how do I get back to 1.639 (is not offered in any release channel), probably via the hash of the last version, but I do not know

  1. Right now Evo comes with translations for English, Türkçe, Svenska, Nederlands and العربية, this is a white list of languages with a good translation coverage. Full list of translations is available at https://translate.directadmin.com/projects/directadmin/evolution-skin/, once specific language translation reaches maturity we will start bundling it with the Evo releases. Idea is to centralize collaboration for translations in a single place and allow all community members to benefit from it. Avoiding everyone to have to translate DA for himself.
  2. Older DA versions (prior to 1.640) used to pull translations from the backend. Starting 1.640 translations are now saved as Evolution assets in data/skins/evolution/assets/translations/{lang}.json
  3. DA version 1.63.9 is available in the current release channel.

Regarding EVO, another input, with cpanel I can now finally include content with the new jupiter theme, I would like to be able to do this with DA, I cannot imagine that it should be a huge effort to integrate this (create file on the file system which will be included if available in header or foother, as is already the case with the hook system).

Content inclusion might come after we finish with Evolution cusomization support upgrade. In the upcoming releases we will be making changes how Evolution stores its customizations, it will be more flexible and less complicated ?. We are getting rid of themes but extend customizations to the point where same changes as were possible with themes now would be available via customizations. Once the migration is done next step could be extending customizations to support adding extra text blocks in various places.

Oh yeah one last thing,I noticed that since recently there are question mark links in the titles in EVO which refer to sitehelper documentation, so far so good but this leads us to more support requests. It would be great if we could turn this off or add own link per page to your own documentation (as a config avariable?).

Could you give us more details why you would like to hide those links? Ideally we do not want for everyone to keep re-inventing the same wheel and creating its own version of site-helper docs. Hence the change towards unified single source of truth documentation. From here we have two directions forward:
  1. Enable site-helper docs to be improved by community by making docs an open repository, where change suggestions can be submitted by the community.
  2. Utilize the customizations support to allow more fine grained control of the docs like (hide or replace).
Understanding the use-cases you face would help us make better informed decisions. To all the feedback is really appreciated.
 
Yes, we will restore language_list to work in 1.640 and leave its removal for later releases.
If you suddenly don't support old things anymore you should mention it in the release notes.


Older DA versions (prior to 1.640) used to pull translations from the backend. Starting 1.640 translations are now saved as Evolution assets in data/skins/evolution/assets/translations/{lang}.json
In data/skins/evolution/assets/translations/ I can’t find the EN lang file, where is this located (I’ve to change some stuff inside because we modified DA a lot and renamed some functions to match old company setups).

Why do you migrate away from the po lang files? This was super handy for translating with tools, also if strings has changed it was easy possible to update with the “directory” file.

What about the backend translations? Are they no longer needed?

How can we use again our own 3 language files? We’ve invested a lot of work to create them and made them perfect for our needs.


DA version 1.63.9 is available in the current release channel.
Thanks, till this morning it was 3.63.8


Content inclusion might come after we finish with Evolution cusomization support upgrade. In the upcoming releases we will be making changes how Evolution stores its customizations, it will be more flexible and less complicated ?. We are getting rid of themes but extend customizations to the point where same changes as were possible with themes now would be available via customizations. Once the migration is done next step could be extending customizations to support adding extra text blocks in various places.
What means “getting rid of themes”? We also created customised themes to let DA exactly looks like cpanel (yes yes I know….). We tried to recreate this on Enhanced basis but discarded it because many new features were not runnable.

Extra text blocks in various places is a huge plus and allow us to stop the most support request by describing the most problems of the clients directly inside the functions.

I would also be very interested to know what exactly you are planning to change about the skin. In the near future I've to replace few more servers, the question is do we migrate them to DA or do we use again the "old solution".


Could you give us more details why you would like to hide those links? Ideally we do not want for everyone to keep re-inventing the same wheel and creating its own version of site-helper docs. Hence the change towards unified single source of truth documentation. From here we have two directions forward:
  1. Enable site-helper docs to be improved by community by making docs an open repository, where change suggestions can be submitted by the community.
  2. Utilize the customizations support to allow more fine grained control of the docs like (hide or replace).
Understanding the use-cases you face would help us make better informed decisions. To all the feedback is really appreciated.
Sure. We had few customers which had read the sitehelper stuff, discovered other topics and came to us with the request to provide functions we had deactivated (which were deactivated for good reasons). Furthermore, there were complaints why everything was in english and not in a compatible language (our customer base is based on 3 languages, none of which is english and supplied by DA). Therefore we would like to refer to our own documentation, this saves and a lot of support effort. And last but not least, most of them do not understand english....

Thanks!
 
If you suddenly don't support old things anymore you should mention it in the release notes.
Yes, as mentioned before, it was not deliberately omitted, just a work in progress got leaked. Thank you for bringing this to our attention. Once we finish up we will properly document it in the change log. For the time being (for 1.640 release) we will just restore old behaviour.

What means “getting rid of themes”?

Old themes required uploading files to the server and was independent configuration layer. We are not removing it but rather merging it with existing skin customization. It means changes that previously required uploading files to the server manually will not be configurable via the GUI. We aim to allow the same level of customizability you had with themes to be available in the skin customization section. So it is not removal but rather merge of different means of customizing Evo into single location.

...our customer base is based on 3 languages, none of which is english and supplied by DA...

Thanks for the feeback. Good point of site-helper being English only. Would you be willing to share your 3 translation files with the rest of us? If you would send the po files to me in private message I could take care of importing them into our https://translate.directadmin.com system. And further translation improvements could be done there.
 
All right, thanks for your accurate answer, sounds reasonable so far.

I'll check if we can release our translations, the company has put a lot of effort in here but as already mentioned we call many things differently, this makes little sense for others (our customers are used to this naming of functions for decades).
 
An update is released restoring the language_list language filter functionality in Evolution.
 
Back
Top