Don't show language code for default language in URL of Django CMS site - django-cms

When I set up a multilingual DjangoCMS powered website the default language code is appended to the URL:
http://mypage.com/ -> http://mypage.com/en
I don't want this to be the case for the default language (e.g. 'en') Instead what I want is the default language being chosen when there's no language identifier within the URL:
http://mypage.com -> Choose English
http://mypage.com/fr -> Choose French
http://mypage.com/it -> Choose Italian
How can this be done?
Versions:
Django CMS 3.0.3
Django 1.6.5
Python 2.7

I wrote this for a project that's currently using it in production, they use django-cms 2.4.3 but I don't see why it would not work on 3.0, all you need to do is create middleware.py file in one of your apps, say core and then replace django's locale middleware with the path to this one, since it's a subclass of it.

I faced a similar situation for a web site based Django CMS version 3.4.5 and Django version 1.8.18. At first sight this seems to be a Django CMS concern, but later I realized this is more related with core Django, which has been natively addressed by the recent versions of this project.
A working solution
The straightforward solution I applied involved these changes:
Upgrade to Django version 1.11.8 (any version >= 1.10 should work). A shell command like pip install Django==1.11.8 --upgrade can achieve this.
Edit the urls.py file to change it like the following:
Original content of urls.py file:
urlpatterns += i18n_patterns(
url(r'^admin/', include(admin.site.urls)), # NOQA
url(r'^', include('cms.urls')),
)
New content of urls.py file:
urlpatterns += i18n_patterns(
url(r'^admin/', include(admin.site.urls)), # NOQA
url(r'^', include('cms.urls')),
prefix_default_language=False
)
Apply Django migrations, which are part of the new version of Django
Run again the Django project and visually verify the new desired behavior
I should mention that someone with the nick FalseID at the #django-cms IRC channel gave me the advice to find this solution, as well as other related tips.
Other references
Existing answer that applies to a general Django project https://stackoverflow.com/a/43911714/6693126 if the version of Django is >= 1.10. This describes a similar situation to mine.
For Django versions < 1.10, this answer is useful: https://stackoverflow.com/a/17517000/6693126 which is based on the django-solid-i18n-urls package. I have not tested this procedure, but it should work.

Related

File to import not found or unreadable: bootstrap-sass

Trying out Django Shop. Following this tutorial: https://django-shop.readthedocs.io/en/stable/tutorial/intro.html (stable).
When I run the server and open localhost, here's what I see:
Error: File to import not found or unreadable: bootstrap-sass/assets/stylesheets/bootstrap/variables.
Parent style sheet: /home/vm/PycharmProjects/Django-shop/django-shop/shop/static/shop/css/_variables.scss
on line 1 of ../shop/static/shop/css/_variables.scss
>> #import "bootstrap-sass/assets/stylesheets/bootstrap/variables";
I presume, this "bootstrap-sass" directory is supposed to be in "css" and I don't see it there.
Only happens on front of the website. I can open admin panel just fine.
The error mentioned in the comment that says No module named 'django.core.urlresolvers' gives you a clue that there is a django compatibility issue. To understand more about this error please refer to this answer on Stackoverflow, which discusses a particular changelog from Django 1.x version to 2.x.
Now that we know that this could be a point of conflict here, refer to Compatibility Table, which clearly states that Django Shop is not compatible with Django 2.x versions as of now and in your project setup when you pip install django, it installs the latest version of django which is 2.1. Therefore to overcome this, you should downgrade the Django to a version thats compatible with your Django Shop version. So a working combination would be Django 1.11 and Django Shop 0.13.x.

How to test a new cloudify plugin with a blueprint that internally uses another plugin?

I'm developing a new cloudify plugin that I test using tox, nosetests and #workflow_test decorator following the plugin template.
I'd like to test the plugin interacting with another plugin (speficially openstack plugin). Hence I'm using a blueprint that imports my plugin (test yaml file) and the openstack yaml file, and then defines some nodes from my plugin and from openstack.
The problem is that I'm getting module python import errors as the openstack plugin is not found in the test environment created by tox/nosetests. I tried installing the plugin using wagon before running nosetests, but the installation fails.
Anyone could indicate me how to do that?
Have you tried requirements files? In your tox.ini file, you should be able to define your test requirements like this:
[testenv:py27]
deps =
-rdev-requirements.txt
-rtest-requirements.txt
Then put either the URL of the branch zip (such as master) in your test-requirements.txt file:
https://github.com/cloudify-cosmo/cloudify-openstack-plugin/archive/master.zip
nose>=1.3
tox
In general, I find the workflow_test not to be very useful, and usually I end up writing something else for the same purpose. For example, these functions basically do the same thing in this test base:
https://github.com/cloudify-incubator/cloudify-ecosystem-test/blob/791f02a27313ac0b63b029c66ead333cb17c4d9c/ecosystem_tests/init.py#L100
https://github.com/cloudify-incubator/cloudify-ecosystem-test/blob/791f02a27313ac0b63b029c66ead333cb17c4d9c/ecosystem_tests/init.py#L151
https://github.com/cloudify-incubator/cloudify-ecosystem-test/blob/791f02a27313ac0b63b029c66ead333cb17c4d9c/ecosystem_tests/init.py#L225

django admin not showing some css and form features

I copied my django (v1.10) source code to my Apache server, and executed the python manage.py collectstatic, it copied 420 files to /var/www/sitename/mainwork/static.
The website's css itself works fine, but the admin does not show some features!
.
It also does not show some links of the forms: (the first snapshot is the way it is supposed to be)
the way it supposed to be:
the way it is, with missing link:
what is causing this problem?
Thanks in advance. (if any code is required just tell me to add here)
Edit1:
This is the console errors related to the third snapshot:
There were different versions of django installed on the server (django 1.8 on apt-get and 1.10 on virtualenv!). and I think it caused a conflict on python manage.py collectstatic. (The website was running with django 1.10, but the admin's static files were from 1.8)
I removed the django 1.8, deleted the static/admin folder, and executed the collectstatic again. and the problem is resolved.

How to find the latest versions of all QML modules

Usually my QML files start with import QtQuick 2.4 and other imports. How can I know which is the latest version of the imported modules without having to guess by type and build?
You basically don't have to know. By importing a particular version, you merely declare that you don't need the additional functionality of any potentially newer version. That doesn't mean that you won't use a newer version if one is available - it simply means that your code will refuse to run if only an older version than the one you need is present.
So, you should only change the imported module version if you happen to use the functionality (members, classes, etc.) from a newer version. That's all. And you will know exactly what version you need, since you're using the functionality you read about in the documentation. The documentation will state what module version it applies to.
The documentation for a given Qt Quick module from the Qt that you're using will state this - no need for release notes.
The QML module version information can be found in a file called plugins.qmltypes.
These files use JSON to store information (as far as I am aware).
In these files Qt uses the "exports" specifier to export the name and version of a module.
Example:
exports: ["QtQuick/Accessible 2.0"]
The example shows the version of the QtQuick.Accessible module.
The plugins.qmltypes are stored in a directory of the same name as base level module.
In the case of the example this would be QtQuick.
Base level modules are grouped under a directory titled qml.
That is "usually" located in a directory called qtx (in some case Qt).
Where x is the installed major version of Qt (in my case it would be qt5).
That means the plugins.qmltypes has a path that looks something like this:
/qt5/qml/QtQuick/plugins.qmltypes
The reason im explaining this bottoms up cause the rest of the path is dependent on how you installed Qt:
Package manager (portage) amd64 install path:
/usr/lib64/qt5/qml/
pip PySide6 install path:
~/.local/lib/python3.9/site-packages/PySide6/Qt/qml/
pip PyQt6 install path:
~/.local/lib/python3.9/site-packages/PyQt6/Qt6/qml
~/.local/lib/python3.9/site-packages/PyQt6/Qt6/qml
Package manager (apt) aarch64 install path:
/usr/lib64/aarch64-{forgot this part}-/qt5/qml/
I figure the version out in bulk with:
grep -r "exports:.*\\]" <insert install/OS dependent path>/qml/* | less
This doesnt grab multiple exports that are spread over multiple lines thought.
Since QML comes in 2 major versions when in doubt you could import version 1.0 or 2.0.

Deployment Symfony 2.4 on Microsoft Azure (git/composer)

For the last two days I'm trying to push my application on Azure but I'm facing problems about the Symfony 2.4 deps (with composer). The main error is :
symfony/icu v1.2.1 requires lib-icu >=4.4 -> the requested linked library icu has the wrong version installed or is missing from your system, make sure to have the extension providing it.
I saw on the internet that the problem could be about the php_intl extension not loaded. So after hours I managed to get it by creating a bin\ext\php_intl.dll in my root directory (the documentation does not mention the ext subdirectory, and it was not working for me when I put the intl into the bin directory).
Internationalization support enabled
version 1.1.0
ICU version 49.1.2
ICU Data version 49.1.2
But I always get the same error. Do you have any idea about this?
Thanks.
Try to add in your composer.json :
require: {
"symfony/icu": "1.1.*"
}
See http://symfony.com/doc/current/components/intl.html, chapter "ICU and Deployment Problems"

Resources