The canonical tag is important for SEO, indeed it prevents search engines from
indexing duplicate content.
Reasoning
=========
The choice has been made to create the canonical tag automatically depending on
the request path, ignoring the query string, and manually prefixing the
appropriate domain and language code.
Indeed creating it manually for each resource would create a lot of code and
potential mistakes.
It is more dangerous to do it the generic way, but after investigation it
appears that it is an acceptable trade-off since the vast majority of our routes
are well built and already ready for this:
- using query string only for minor features that do not change the main content
- having the models, the ids, the pager and other important features in the path
Override
========
It is still possible to override the default behavior by passing
`canonical_params` manually to the view or to the different methods.
This is done for `/event` because the only way to display Past Events is to add
`date=old`.
Languages
=========
Fix an issue where it was possible for a bot to be on the URL without language
code but to use a language that is not the default language.
Adapt hreflang, because it:
- must only be present on canonical pages
- must always lead to canonical pages
- should not be set if there is no alternate language
Misc
====
task-1958075
closes#12532
Inspired by OCA module `website_canonical_url` courtesy of Jairo Llopis.
closesodoo/odoo#35852
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Jairo Llopis <jairo.llopis@tecnativa.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
With this commit it is now possible to change the lang displayed in the URL.
Eg, you could use `/fr` instead of `/fr_BE`, or even a fancier `/french`.
Task-32838
Courtesy of pla@odoo.comclosesodoo/odoo#35135
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
get_installed and _lang_get_id are both ormcached and correctly check
the context
Retrieving a res.lang from a code is a frequent action that can be
achieved with _lang_get (cf previous commit).
Using _lang_get ensure the active_test in the context is correct and
is not poluted with another context propagation issue.
odoo/odoo#35490 discussion is an example of bad context propagation
closesodoo/odoo#35504
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
cache_hashes was introduced at 8a28cc22fd to reduce the number of reload
The cache is correctly reseted when the translations content changed but did
not contain all the translation-related parameters that are, however, stored
in the session_info
This commit fixes two bugs:
Language parameters invalidation:
1. Access the webclient in a specific language
2. Modify the language parameters (e.g. thousands separator)
3. Refresh the page
--> webclient is still using old language parameters (from cache)
No translation flag after installing a language:
1. Load a database in English in mono-language
2. Load a second language
3. Access a record with a translated field
--> translation button not present on translated field (multi_lang is still
false in cache value)
To fix it, this commit adds all the information that are returns by the
/web/webclient/translations call to make sure the hash represent the reality
closesodoo/odoo#34266
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
* http_routing, portal, rating, survey, website, website_survey,
website_slides_survey
Before this commit, the final base layout of website was a fully
overridden layout of the one in portal, which was somehow a duplicated
one of the login one in web, which... so lots of duplicated code.
This commit is a first step towards a better organization:
1) The web app defines a frontend layout (to include base frontend
assets), with a base company logo as header.
2) The portal app modifies that layout in place to include the base
header, footer, ... It also uses a primary extension of it for
portal pages.
The survey app simply uses the above layout instead of defining its
own (by primary extension to include its own assets for its own
pages)
Same goes for the rating app and pages.
3) The website app modifies that layout in place to include the UI
assets, to add website UI, ... This allows to create frontend apps
which do not depend on website, with a non duplicated layout that
will be automatically adapted if website is ever installed (this
therefore allows to get rid of website_survey definitely)
This commit also fixes the session info system and the translation URL
on the frontend side to not require to redefine the whole session_info
for portal, website, ... Now the frontend session_info is defined in web
and http_routing extends it to add translation informations, then
website extends it again to add its own elements (not to redefine them
all as before). Note: before, http_routing defined the translation route
but only portal was adding it in its layout...
This is an adaptation of the work that was done with commit
https://github.com/odoo/odoo/commit/99821fdcf89aa66ac9561a972c6823135ebf65c0
Note 1: Many frontend but non-website apps (not only survey / rating)
could probably use this too but this would be the topic of another task.
Note 2: survey currently depends on http_routing but does not add itself
in the list of frontend apps to translate, it probably should.
Note 3: web_editor does currently not depend on http_routing but does
add itself in the list of frontend apps to translate, it thus uses a
function it does not really depend on... to check after its work-in-
progress refactoring.
task-1961045
closesodoo/odoo#33825
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Reintroduces 5324284f5 that was reverted because in the case of an URL
like /payment_stripe/static/src/js/stripe.js directly inside a QWeb
template, we would possibly get:
/fr_FR/payment_stripe/static/src/js/stripe.js
Which is not accepted by werkzeug SharedDataMiddleware we use to serve
static data in /{module_name}/static/ directories.
Added test without changeset failed with:
- test_process_att_no_request_lang: <AssertionError>
line: self._test_att('/en_US/', {'href': '/'})
wrong result: {'href': '/en_US/'}
- test_process_att_with_request_lang: <AssertionError>
line: self._test_att('/', {'href': '/fr_FR/'})
wrong result: {'href': '/'}
- test_process_att_matching_cdn_and_lang: <AssertionError>
line: self._test_att('/en_US/a', {'href': 'http://test.cdn/a'})
wrong result: {'href': 'http://test.cdn/en_US/a'}
- test_process_att_no_route: <AssertionError>
line: self._test_att('/my-page', {'href': '/fr_FR/my-page'})
wrong result: {'href': '/my-page'}
- test_process_att_url_crap: <IndexError: list index out of range>
line: request.httprequest.app._log_call[-1],
opw-1922051
closes#32095
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This reverts commit 5324284f56
This reverts commit ad826f56ba.
If for example we had in a template:
<script type="text/javascript" src="/payment_stripe/static/src/js/stripe.js"></script>
it has been reproduced to be gotten as:
<script type="text/javascript" src="/de_DE/payment_stripe/static/src/js/stripe.js"></script>
which is unexpected and could cause an error.
closes#32090
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
With 953a693df when a route is not found we assume it is a website.page
that can be multilang.
But with #31792 we should once again prefix URL by the language if
necessary.
The combination of the two cause issue when an url like `/web#home` is
tested since we do not take `#` into account, we check if the route is
multilang but no route `/web#home` is found => so we get
`/fr_FR/web#home`.
With this fix, `#fragment` is not taken into account when searching
route.
related to #31792
related to opw-1922051
closes#32059
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
web (tagged with `openerp-web`) translations are loaded in the backend, in
`odoo.addons.web.controllers.main.WebClient.translation(mods=None, lang=None)`
method (through `/web/webclient/translations` controller).
In website, the controller `/website/translations` is called used, fetching
the translations from modules with the (fragile) clause `name ilike 'website'`
This commit fixes two bugs:
1. Install `website_sale`, activate discussion on products
-> the chatter is not translated as the portal translations not loaded in the
`/website/translations` controller
2. Install `helpdesk` but not `website`, go to portal view of a ticket
-> the heldesk chatter is not translated as the `/website/translations`
controller is not called (only provided by the website module)
This patch implements a modular approach to translate the web resources of the
right modules only.
The controller /website/translation is moved to http_routing and each module
override the new _get_translation_frontend_modules_domain method to adds its
translatable module
Closes#23618Fixes#23610
Before this commit, if you call a route with an missing ID, you
see an internal error 500 "Record not existing" (MissingError)
It has been intriduced by commit 9dc173cc2e
Now we catch the missing Error and return explicitely a 404 exception.
Clean method _add_dispatch_parameters
Remove unused code for caching
Call super before to have the correct lang when we browse website.
Without it, menu was not loaded in correct language.
This reverts partially commit ab2283ef83.
This commit clean and clarify some code.
It also secure the call to specific page extension's template to avoid somehow
calling unexisting tempalte
Before this commit:
1. You could create a page with supported extension in the path (eg: myfile.js)
You would then be redirected to the webeditor (myfile.js?enable_editor..)
But in this case, it would just redirect you to a plain text page without odoo
layout because supported extension are rendered with a specific mimetype.
(is it is a .js page, it will just render the page content as a js file)
2. These kind of page would still call t-layout that you should be removed in
backend in order to make it work
Now:
1. You will be automatically redirected to the back end to edit your file
instead of landing on a text-only page.
2. Supported extension now have their own template (eg: .js file now have
<script text=..> tag added automatically in their content)
Before this commit:
website.page won't be rendered as translated items since it is not going though
a controller (route) enabling multilang. Website.page were not considered as
multilang items and no lang prefix were applied on link.
Now:
website.page will correcly handling translation.
In case of one route doesn't match a controller, it is now by default a route of
type multilang.
Add a new field auto_redirect_lang on website model to allow to deactive the
autoredirect of the lang optionnaly. The code will arrive after more tests.
website.page = old ir.ui.view with page=True
website.redirect is a new mechanism to replace in the futur the ir.attachment
mechanism of redirect.
From now, we don't have a specific /page controller to serve 'page'.
We use a new model website.page which is rendered if none route matches the url
and that the field 'url' on website.page matches the request.httprequest.path.
The order to serve a path is:
- Routes defines in controllers (/shop, /blog, ...)
- ir.attachment with name matching the path
- website.page with url matching the path
- website.redirect with url_from matching the path
- 404
To improve:
- allow regexp in website.redirect model
- allow to edit the view_arch from the page.management via redirect backend
(needed when traceback in the page, or when modifying a js/css/less/...)
This merge mainly does 2 things:
- move frontend chatter feature from website_mail
into portal, since chatter is required for some
business model in the customer portal. This chatter
is still also responsible of displaying comments
for website object (slides, blog, ...)
- bring project customer portal into project,
and make project module depends on portal, like
it was already done for sale and account.
hr_timesheet now contains the dislaying of timesheet
on task in portal.
website_project is removed, and we do not use
website.published.mixin on project, since this
is only used to display its rating. projects are
not public object.
As customer portal will be moved to portal module support of pager
has to be moved previously to the various portal moves. This commit
moves the pager code and template to portal.
Compatibility using website-based pager is provided to avoid having
to update all website addons currently. Future commits will make
addons use the portal pager instead of website pager.
Code managing language in URLs and redirection is moved from website
to http_routing. Override of _dispatch in website now consists in adding
website to the request.
url_for and is_multilang_url tools methods are also moved from website
to http_routing.ir_http as those are required for the moved code.
Some renaming is performed on request attributes previously added in
website. Indeed as website keyword may be misleading now a renaming
has been performed to better understand them :
* request.website_enabled -> request.is_frontend
* request.website_multilang -> request.is_frontend_multilang
* request.httprequest.cookies.get('website_lang') -> ('frontend_lang')
* first_pass variable in _dispatch is replaced by a new attribute of
request, routing_iteration, that is the number of routing iterations
currently done
ir_http override in website manage languages through methods or attributes
directly defined on website model. Those methods are get_languages method
and default_lang_code attribute. In order to be able to have a translation
layer independent of website we have to have access to this data without
depending on website record.
This commit solves this by adding class methods on ir_http override
located in http_routing. Basic implementation comes directly from website
default methods _active_languages and _default_language. Website overrides
those methods in order to be based on website values defined through
language_ids and default_lang_id for available languages and default
language.
Website behavior is therefore untouched whereas http_routing implements
a basic default behavior. This commit updates ir_http code in website
to use those methods and ease next commits which will move parts of that
code.
Slug and unslug API is now available in http_routing. Indeed there is no
link to any website or any reason to not support slufigied URLs when
website is not installed. A new unslug_url method is added as a tool
coming from an embedded method from website. Doing it allows to have all
slug related methods defined at the same point.
Support of slug and unslug in qweb rendering is also moved directly in
http_routing version of ir_ui_view instead of website inheritance. This
is done in order to keep things coherent.
Some code from website about ModelConverter is also moved. Indeed both
versions of ir_http uses some kind of placeholder to store the uid
when converting urls to python. This commit unifies it by using the
website one directly in base to simplify the override.
This commit also updates all module importing slug. Enterprise modules
will have to be updated, see related commit.
This module will contain http routing capabilities that are not
necessarily linked to a website. This covers for example code related
to language management in URLs or slugify support.
Advanced http routing are not moved in base in order to keep the core
simple. It is not moved in web because this module should contain only
interface and not http / routing code. http_routing module will therefore
be used to hold those features.
This commit only adds a void module, future commits will gradually add
the various features through dedicated MOV commits.
