Frequently Asked Questions

Donate to plugin development.

If you are new to qTranslate-X, please, read Startup Guide.

If you think you encountered a bug, please follow the Troubleshooting Guide and then report it providing step-by-step instructions how to reproduce the problem, preferably starting from a fresh standard WordPress installation.

If you have integration issues, please read Integration Guide to find out how to integrate your theme or a 3rd-party plugin with qTranslate-X.

 

# Is my language supported or included?

Yes, all languages are supported and more and more get included. If yours is not included, you can easily add it through the Language Manager (/wp-admin/options-general.php?page=qtranslate-x#languages). If you are a native speaker of that language, consider sending us the information to be included permanently in the plugin configuration.

Help us to keep this plugin free.
 

# What language switching methods are available at front end?

1. Add menu item “Language Switcher” to an appropriate menu on your site. It has a few customizable options as described in the embedded help text at menu configuration page or in other FAQ topics.
2. Add widget “qTranslate Language Chooser” to an appropriate widget area on your site. It has a few customizable options as described in other FAQ topics or embedded help text.
3. Use direct call to qtranxf_generateLanguageSelectCode($type,$id) in your templates (pay attention to prefix ‘qtranxf_‘  instead of  ‘qtrans_’). Argument $type currently accepts ‘image’, ‘text’, ‘both’, and ‘dropdown’ choices, which match the choices available in “qTranslate Language Chooser” widget. Example: <?php echo qtranxf_generateLanguageSelectCode(‘both’); ?>. You can change the look of language select list via CSS entries.
   
   Starting from the version 3.4.6, the arguments of the function are changed (compatibility with old way is preserved): qtranxf_generateLanguageSelectCode($args). A single argument $args is a hash array of options, which accepts the following keys:
   • ‘type’ – one of the values: ‘text’, ‘image’, ‘both’, ‘dropdown’ and ‘custom’, which match the choices on widget admin page.
   • ‘format’ – needs to be provided if ‘type’ is ‘custom’. Read help text to this option on widget admin page.
   • ‘id’ – id of widget, which is used as a distinctive string to create CSS entities.
4. Use a call to WordPress method “the_widget('qTranslateXWidget', $instance, $args)“. Argument #instance takes the following keys:
   • ‘widget-css-off’ – boolean value, default is ‘false’.
   • ‘hide-title’ – boolean value, default is ‘false’.
   • ‘hide-title-colon’ – boolean value, default is ‘false’.
   • ‘title’ – string value of widget title.
   • ‘type’ – string value with possible values ‘text’, ‘image’, ‘both’, ‘dropdown’ and ‘custom’. Type ‘custom’ is only available in version 3.4.6 or later.
   • ‘format’ – string value of custom format, in case ‘type’ is ‘custom’. Read help text to this option on widget admin page.

   For example, the_widget('qTranslateXWidget', array('type' => 'both', 'hide-title' => true) );. Refer to the documentation of function the_widget for more information.

5. Build a few custom menu items, each of which switches the current page to a specific language. The visual appearance of such menu items can be designed any way as desired, like any other normal menu item.

Help us to keep this plugin free.
 

# I used to make direct calls to one of qtrans_* functions in my theme/plugin, but now those functions are not available.

WordPress policy prohibits use of the same function names if they already defined in other plugins, since this possibly leads to user-unfriendly fatal errors. That is why all functions with prefix qtrans_ were renamed to have prefix qtranxf_. However, once the plugin is running and all other conflicting plugins are disabled, you can turn on option “Compatibility Functions” and a number of former qTranslate methods with prefix qtrans_ become available again. This ensures compatibility with other plugins and themes that used direct calls to qTranslate methods in their code.

Note: Function qtrans_modifyTermFormFor, which some older themes or plugins call directly, is no longer available and should not be needed with qTranslate-X. This function used to deal with multiple input lines per language, which qTranslate-X does not use anymore. That multi-line framework is now replaced with Language Switching Buttons (LSB). Please, ask the authors of those themes and plugins to update their code, if you encounter one of those cases. In most of the cases, they would simply need to remove that extra code, otherwise  Integration Guide may help.

 

# On the first visit of my site with home URL, I get other language than the browser’s displayed one, even after I cleared all the cookies.

Many browsers have additional option “Preferred Languages” or have a way to sort the languages by preference. The browser’s displayed language may not be set at the top of preferred languages. Check the settings.

Help us to keep this plugin free.
 

# Is it possible to translate theme custom fields?

Yes, some themes put additional text fields per page or per post. By default, those fields have no way to respond to Language Switching Buttons in editors. However, you may enter “id” or “class” name attribute of those fields into “Custom Fields” section of “Languages” configuration page in “Settings”, and they will then respond to the language switching buttons allowing you to enter different text for each language. To lookup “id” or “class”, right-click on the field in the post or the page editor, choose “Inspect Element”, and look for which attributes are defined for that field. If you cannot uniquely distinct the field neither by if nor by class, report on the forum threads.

The theme must pass those values through translation function __() before displaying on the front-end output. If this is not done, you will see the text of all languages displayed one after another. Most themes use __() translation by default, otherwise you may ask theme author to make this little modification for each field you need to be translatable. However, sometimes, they pass a value through apply_filters() function before displaying the value, and then you may put that filter name into configuration filed “Custom Filters” to get the value translated properly.

The following fields are pre-configured to be translatable by default:

• all input fields of class “wp-editor-area“, which normally include all TinyMCE visual editors.
• fields with the following id: “title”, “excerpt”, “attachment_caption”, “attachment_alt”.

This applies to post, pages and media editors (/wp-admin/post*).

Read Integration Guide for more information on how to integrate qTranslate-X with a 3rd-party plugin or a theme.

Help us to keep this plugin free.
 

# How do I translate custom configuration fields, which are not handled by language switch buttons?

Some themes have additional to the standard WP design fields, which need to be translated. In such a case, try entering all the translations in one field using raw multilingual format (Raw ML) like this:

[:en]English Text[:de]Deutsch[:]

or like this (obsolete way)

<!--:en-->English Text<!--:--><!--:de-->Deutsch<!--:-->

You may also embed language-neutral text in-between the language-specific content, like this:

<html-language-neutral-text>[:en]English Text[:]<html-language-neutral-text>[:de]Deutsch[:]<html-language-neutral-text>

Note that closing tag right before the opening tag is redundant. For example, the following encoding is equivalent to the example above:

[:en]English Text[:][:de]Deutsch[:]

Two encoding modes are interchangeable, although most people prefer to use square-bracket style ‘[:]’, because it is shorter and easier to edit.

If a theme uses translate function __() before displaying those fields, then they will be shown correctly, otherwise suggest theme author to put __() calls in. Most themes do it this way.

Many plugins and themes pass a value through a call of filter function apply_filters('name_of_filter',$var) before printing the value on the screen. If this is a case, then one can put 'name_of_filter' into “Custom Filters” option of qTranslate-X to make such field appear translated at the front-end.

Read Integration Guide for more information on how to integrate qTranslate-X with a 3rd-party plugin or a theme.

Help us to keep this plugin free.
 

# Can I change the look of Language Switcher Menu?

The following query options can be typed in the field “URL” of “Language Menu” custom menu item, after “#qtransLangSw?”, separated by “&”, same way as options are provided on a query string:

• type=[LM|AL] – type of menu:
  • “LM” – Language Menu (default).
  • “AL” – Alternative Language: the top menu entry displays the first available language other than the current.

• title=[none|Language|Current] – title text of the top item (not sub-items):
  • “Language” – word “Language” translated to current language (default).
  • “none” – no title in the top of menu, flag only.
  • “Current” – displays current language name.
  • One may also put arbitrary multilingual title in the field “Navigation Label” in the menu item editor.

• colon=[shown|hidden] – whether to display colon after title.

• flags=[none|all|items] – the way to display language flags:
  • “none” – no flag is shown in any item, including the top item.
  • “all” – all items show flag, including the top item.
  • “items” – only sub-items show corresponding flag, top item does not.

• names=[shown|hidden] – whether to display language names in sub-items.

• current=[shown|hidden] – whether to display the current language in the menu.

For example, to show flag only in the top language menu item, enter #qtransLangSw?title=none, if in addition to this current language is not needed to be shown, enter #qtransLangSw?title=none&current=hidden, and so on.

We understand that this is not a very user-friendly way to adjust the options, but it works, and we will provide a better in-editor interface to specify them in the future.

Help us to keep this plugin free.
 

# Flags and text are misaligned on language menu or widget.

Theme or other plugins CSS entries interfere. Adjust applicable CSS entries through a custom stylesheet.

 

# Home URL does not switch language properly.

• If you test it with manual typing of language-neutral URL which gets redirected back to previously active language, then read “Browser re-direction based on language“.
• Check for anything funny in .htaccess file.
• Did you turn on option “Disable language client cookie ‘qtrans_front_language’ (not recommended).” on page /wp-admin/options-general.php?page=qtranslate-x#advanced? Then turn off option “Detect Browser Language” on page /wp-admin/options-general.php?page=qtranslate-x#general.

 

# How can I prevent URL of a custom menu item from being converted

URL of a custom menu item gets converted to a URL for active language according to option “URL Modification Mode”, unless query argument 'setlang=no' is added to the URL typed in. For example, if URL of a menu item is http://example.com change it to http://example.com?setlang=no, or if it already has some query like this http://example.com?arg=value, then change it to http://example.com?arg=value&setlang=no. The additional query 'setlang=no' is always removed when the item gets rendered on a web page, for example:

• http://example.com is rendered language-encoded, like http://example.com/en.
• http://example.com?setlang=no is rendered as http://example.com without language encoding and argument 'setlang=no' is removed.
• http://example.com?arg=value&setlang=no is rendered as http://example.com?arg=value without language encoding and argument 'setlang=no' is removed.

 

# How can I make URL of a custom menu item to be always converted to a specific language?

Put into field “URL” of a custom menu item entry like “#?lang=xx“, where “xx” is a two-letter language code desired. On front end, this menu item will point to its own page and will always stay converted to the language specified regardless the active language.

Using a few menu items like this with different languages provides an alternative way to build a horizontal language menu, or any kind of custom language menu, instead of pre-configured Language Menu item.

The menu item’s “Navigation Label” may still be customized depending on active language in a normal way like in any multilingual field. You may also put a picture in the menu (probably flag, if used for language menu) by putting code like this

English <img alt="English" src="http://localhost/wordpress/wp-content/plugins/qtranslate-x/flags/gb.png">

into field “Navigation Label”.

 

# Can I make horizontal language menu instead of a drop-down one?

Use a widget with CSS tuned for horizontal list, or, if in menu, use a set of custom menu items instead of pre-configured drop-down Language Menu. Configure each item to always switch current page to a specific language as described in the topic above.

Help us to keep this plugin free.
 

# Why a menu item does not follow the translation of the title on the original underlying page or post?

WordPress fetches the menu label from an underlying object attached to menu item, if menu item’s own value for “Label” is empty in database. It becomes empty, if the label entered is exactly the same as title on underlying object, like page or post. Once the value of label and title of underlying object are different, menu will show its own version. That is why, if you wish menu item to follow the title of underlying page, enter exactly the same translations for all languages. Note that even extra space will make the values to be different. Sometimes it is easier to remove menu item, save menu, then add item back. It maybe easier to match all the translations exactly using Raw Editor Mode.

Help us to keep this plugin free.
 

# Can I enable Language Switching Buttons on my plugin custom page?

[obsolete, although should work, use Integration Guide instead] Yes, enter the relevant and distinctive part of your page URL into “Custom Pages” configuration option. When page is loaded, two Java scripts will be added, “admin/js/common.js” and “admin/js/edit-custom-page.js”, from which you may figure out how it works. The Language Switching Buttons will control fields listed in “Custom Fields” option. Those fields will now store the input for all enabled languages. It is up to the theme and other relevant plugins, if those field values will show up translated on the front-end. Some theme and plugins pass the values through __() translation function and then values are translated. They might use apply_filters method, and then name of that filter can be listed in “Custom Filters” configuration option, in order to get the field translated on the front-end.

If your case is still cannot be handled in this general way, you may develop your own Java script, similar to “admin/js/edit-custom-page.js”, and load it from your own file path using “qtranslate_custom_admin_js” hook. Looking through other “admin/js/edit-*.js” scripts may give you an idea how to do yours.

This is a work in progress and any suggestions are appreciated. We will probably end up using some kind of an xml configuration file customizable per each plugin/theme which needs to be integrated. Such an xml-file will list pages with queries affected (“Custom Pages” option for now) along with ids and classes of fields on each page to have multilingual data either for editing or for display.

Ideally, only such an xml configuration file will need to be created in order to integrate a plugin or theme without additional coding.

Help us to keep this plugin free.
 

# How can I customize menu depending on the language?

If you wish a menu item not to show up for a specific language, remove its translation for that language from “Navigation Label” field in menu editor.

 

# Why does my menu show different subsets of items for different languages?

A menu does not show items that do not have translation to the currently active language. Do your missing items have translations in the current language? Try to re-save them to ensure that all translations are entered for all menu items.

Earlier versions of qTranslate-X have shown the default language in some cases, when translation was not available. The latest version is now more consistent with this regard and never shows an empty item. Item appears to be empty if there is no translation. This was requested by users, since people wanted to hide menu items which would point to an untranslated page, for example. This behaviour provides such opportunity. Translation may coincide with another language, but must not be empty.

 

# Are comments multilingual?

Yes and no. Users can type comments in any language they want, but plugin is not aware of the language users used in comments and does not track the languages in use for comments.

Normally, it is considered a responsibility of user to read the comments in any language and to translate them as needed using other external tools like Google Translate, for example.

However, there are 3rd-party plugins, which allow to separate comments by language, although it may make little sense, since you would rather wish to show all comments and let user to decide which one they want to read.

Some integration plugins, track the language of other items of importance, like Woocommerce & qTranslate-X, for example, tracks the language of order.

As to comments, we leave it up to user.

Help us to keep this plugin free.
 

# I am a developer, which functions should I use to translate the raw multilingual values to a specific language?

For the full developer guides, read pages Integration and PHP Developer Interface. The most frequently used key points are reiterated here for the sake of convenience.

If you need to translate a value to other language, use code like this:

$text = apply_filters('translate_text', $text, $lang=null, $flags=0);
$term = apply_filters('translate_term', $term, $lang=null, $taxonomy=null);
$url  = apply_filters('translate_url', $url, $lang=null);

All three accept strings, as well as arrays and objects, as arguments and so will be returned converted to the language specified by two-letter code provided by argument $lang, which defaults to the active language, if omitted.

Standard WordPress function get_locale() returns a locale of active language.

Pay attention, that all calls to multilingual framework must be done after it is initialized in the action ‘plugins_loaded’ with priority ‘2’. Calls to function get_locale(), for example, within your plugin file outside of any function will not work properly in a general case, since language is not yet detected and multilingual framework is not yet initialized. Place your code into an appropriate action or filter, for example, action ‘plugins_loaded’ with normal priority will do.

We discourage people to make direct calls to the plugin’s functions. Normally, one can get away with safe calls to apply_filters. Let the team know about other desirable filters.

 

# I am a developer. Following the logic of the plugin, I expected to see term names in wp_terms table in Raw ML format, but instead, I see the default language values only. Where the translations of terms are stored?

• Table wp_terms has “name” in the default language. If the default language uses non-latin alphabet, the values may be scrambled with %xx encoding in the database.
• Option “qtranslate_term_name” stores the translations of terms with mapping like "term_name_in_default_language" => array("xx" =>"xx_name", "yy" =>"yy_name", "zz" =>"zz_name", ... ). This associative array is accessible at run time via global variable $q_config['term_name'], which should never be used directly in a 3rd-party code.

This may change in the future, but for now, we keep maintaining the original design.

However, this should not be of user concern, since all functions like get_term() or get_terms() bring properties “name” and “description” in Raw ML format at admin side, or already translated to active language at front end. The Raw ML values are also get cached in property i18n_config of WP_Term objects at front end, in case a developer still needs them for some reason.

# I am a developer, how can I retrieve raw values for translated options?

At front end, many multilingual options get translated so that call to function get_option() returns a translated to active language value. Sometimes a developer needs to get a raw untranslated multilingual value, usually to be able to get a translated value for other than active language. One may retrieve such raw value with a code like this:

$alloptions = wp_load_alloptions();//returns loaded/cached values. there is no overhead at runtime
$raw_value = $alloptions['option_name'];

It may also help to read developer notes provided in the previous topic of this FAQ.

 

# I am a developer, how can I alter global configuration of qTranslate-X for the specific purpose of my plugin?

You can use add_action for hooks 'qtranslate_loadConfig' and 'qtranslate_admin_loadConfig' to alter the configuration stored in global variable $q_config. Read more in Integration Guide.

 

# Can I translate slugs?

Plugin Qtranslate Slug is semi-integrated, will work on some configurations, but it is not safe, generally you will end up with some problems. It needs a better integration with qTranslate-X.

 

# Is [:] necessary at the end of multilingual string?

Generally, yes, it is needed. Oftentimes, it works fine without ending tag, it depends on how ML value is in use. For example, __('[:en]en-text[:xx]xx-text') will work the same with or without ending tag. Now, consider that this value was stored in a variable $ml, and then theme uses it inside some other text, for example, __('<language-neutral text>'.$ml.'<other language-neutral text>'). Then you can see that for ‘en’ language you will get “<language-neutral text>en-text” instead of intended “<language-neutral text>en-text<other language-neutral text>”. Things like that happen routinely in complex themes.

In the future, we plan to improve performance of the plugin by removing all little translation filters and translating the whole resulting page with many embedded multilingual values at once. If ending tags are not there, this would not work at all.

That is why you should always use ending tag [:], just in case to prevent any possible problems.

 

# Does plugin support Right-To-Left (RTL) text?

Yes, it does. RTL should get enabled by WordPress based on locale of active language. If you turn the plugin off and switch the whole WordPress to RTL language, it should work correctly, and then it should continue working the same way when qTranslate-X is active. If it does not work right without qTranslate-X, then start your research from WordPress RTL documentation.

Help us to keep this plugin free.
 

# Can I build Google XML Sitemap, including pages with all different languages?

Use plugin Google XML Sitemaps or use “XML Sitemaps” feature of plugin Yoast SEO running together with integrating plugin Yoast SEO & qTranslate-X. You may also use Google XML Sitemaps v3 for qTranslate, which is now seems to be abandoned and unsupported anymore. There might be other sitemap generators out there compatible with qTranslate-X, if you find one, please report it to us.

 

# How do I customize images for flags?

If you wish to use different flag images, point option “Flag Image Path” to your own folder, containing custom images outside of “plugins” or “themes” folders, where it will not be overridden during an update. Most people would put it somewhere under “uploads” folder.

 

# Can featured image or any other media images be multilingual?

Current version does not support multilingual media images. It seems to be an inappropriate though, as it would be hard to maintain and would blow up the server disk usage. However, image title, caption and alt text are multilingual fields and their values can be shown on the top of images with CSS configuration, if desired.

 

# After activation qTranslate-X my front page goes into an infinite redirection loop.

qTranslate-X redirects to a canonical URL before rendering a page, which is necessary for some plugins (BuddyPress, for example) to work correctly. Canonical URL is defined based on options “Site Address (URL)” and “WordPress Address (URL)” from page /wp-admin/options-general.php, option “URL Modification Mode” from /wp-admin/options-general.php?page=qtranslate-x [read more].

If .htaccess then redirects to a different URL, an infinite redirection loop may occur, which can be fixed after proper editing of .htaccess file. In most cases, the default .htaccess from hosting service provider works correctly.

Help us to keep this plugin free.
 

# Why does my browser show unexpected language, if I go to root url ‘/’?

Many people (mostly former qTranslate users) start report of a problem similarly to this: “I have option ‘Hide URL language information for default language’ on, but when I go to a language-neutral URL, it shows non-default language.” In short, it is because the active language is kept in cookies and whatever language user chose in the recent browsing is kept on language-neutral URLs for the sake of user convenience. Or it may happen on the first visit, when no cookie is yet set, and then it switches to the preferred language of user browser.

One has to use language-encoded URL in order to switch language. You may find useful to read the explanation of Browser Redirection Based on Language.

Help us to keep this plugin free.
 

# Why my list of pages shows “Languages are not set” in the “Language” column?

It means that there is no translation entered yet. Just start populating the translations and you will see the list of languages populated instead of “Languages are not set”. Until at least one alternative language is populated in the content, all languages show the same text.

 

# I would like to change two-letter language code for one of my languages. Is that possible?

Yes, it is possible, but it is not simple, since once configured, all the multilingual entries get that code in language tags ([:xx], {:xx}, <!--:xx-->) and qTranslate-X may not be aware of some custom multilingual values to change all automatically.

If you really need to change one of the two-letter codes, then you may dump your database in a .sql text file, then replace all language tags with what you need and import the changed database back to the server.

Do not forget to also set the new two-letter code in the configuration of language properties at page /wp-admin/options-general.php?page=qtranslate-x&edit=xx.

 

# Will be translations lost if plugin deactivated and then activated again?

When plugin is deactivated, no changes to database is done. All translations are kept and safe. Sometimes it is good to deactivate plugin to see all the raw multilingual values on admin side as well as on front end for troubleshooting purposes.

 

# How do I remove qTranslate-X?

When plugin is deactivated, all multilingual values are shown raw at front end. The database needs to be cleaned up if you no longer plan to use the plugin.

Currently, there is no such function within the plugin. You may try to use 3rd-party plugin qTranslate Cleanup, which we never had a chance to test. If you happen to implement a script to do such cleanup properly, let us know.

Starting from version 3.5, there is a choice “Split database file by languages” for option “Convert Database” on page /wp-admin/options-general.php?page=qtranslate-x#import, which allows to split .sql database file of multilingual site into separate single-language database files.

In complex cases with a lot of non-standard multilingual fields, you may choose to request a paid job to split your database into separate single-language databases for each language you have.

Help us to keep this plugin free.

 

# What is wrong with the original qTranslate?

qTranslate still works fine at frontend, except one known to me bug of incorrect date display in comments for some themes. However, its backend breaks tinyMCE content editor in post editing page. Many people have been reporting the problems, but the author keeps silence. qTranslate-X uses the same database backend, and updated admin interface with a slightly different design.

Help us to keep this plugin free.
 

# Does qTranslate-X offer anything new besides bug fixes of qTranslate?

Yes, there is a number of new features, mostly of a convenience significance, which includes, but not limited to:

• A different design of language switching via conveniently located buttons (same way as it is done on zTranslate. No multiple lines for title fields anymore. This design simplifies backend programming and is less likely to be broken on future WP changes.
• “Language Switcher” menu item on WP menu editing screen.
• Category and tag names in the lists on editing pages also respond to language switching and will display the taxonomy names in the currently editing language.
• Theme custom fields can be made translatable in addition to the default translatable fields.

Help us to keep this plugin free.
 

# Does qTranslate-X preserve all the original functionality of qTranslate?

The correct strict answer would be ‘No’, although some sites may never notice it. What is modified, is changed for a reason to provide better support for WP general design and policies, and to ensure better survivability on WP, themes and other plugins updates. While it may cause temporary grief and pain, it should work out better in a long run. Below is a list of the most important changes.

• behaviour of function home_url() is changed to consistently and always return language-enabled URL. This allowed to provide better compatibility with other plugins and themes, some of which used to modify their code to offset inconsistent behaviour of former home_url(). Those tricky changes will have to be now undone.
• language detection algorithm is modified to ensure canonical URL to be processed, otherwise we first redirect to a canonical URL.
• language detection within AJAX calls has been improved and custom compatibility modifications in other plugins and themes may now become unnecessary.

Help us to keep this plugin free.

 

# When I try to use Grid Templates of Grid Builder of WPBakery Visual Composer, my front end gets heavily messed up with language tags like [:xx] shown around my items in the grid. What am I doing wrong?

Grid Templates (/wp-admin/edit.php?post_type=vc_grid_item) need not to be a multilingual objects, since they get inserted into other multilingual fields. Embedded multilingual fields are not implemented in qTranslate-X, and it is not generally needed.

Make sure to turn off checkbox “vc_grid_item” in option “Post Types” on page /wp-admin/options-general.php?page=qtranslate-x#advanced in order to make Grid Templates not to be multilingual. Then create a separate templates for each language instead, and insert an appropriate template into pages content as needed.

You may need to re-enter some information in some pages after turning off the checkbox “vc_grid_item”. In worst case, re-create templates and pages cleanly. Alternatively you may do those edits manually in database, removing language tags meaningfully, if you have advanced enough knowledge on database handling.

You may be using WPBakery Visual Composer without realizing it, as it may be included in your theme. If you have problem with “Grid Builder”, “Grid Templates”, “Backend Editor”, etc. and you have item “vc_grid_item” listed in the option “Post Types”, then the above is most likely applicable to you.

 

# How do I report a bug?

If you think you encountered a bug, please report it here, providing step-by-step instructions how to reproduce it, preferably starting from a fresh standard WordPress installation.

 

# How can I support the development team?

• Donate money.
• Submit pull request at GitHub with a code contribution.
• Write a review at WordPress repository.
• Write a letter to the development team.
• Link one of the pages on this site on your blog.