Github
[4.0] Tag created data has additional offset
Reported by user abs66 at https://forum.joomla.de/thread/14246-fehler-bei-der-tag-bearbeitung/. ### Steps to reproduce the issue 1. Set your server time (System - Global Configuration - Server) to something different from UTC. Testing this is more intuitive, if your server is actually located in this time zone (e.g. CEST = UTC+2). Otherwise, you'd have to do the appropriate calculations in order to check if the time fits. 2. Check the time zone setting of your own user (top right: User Menu - Edit Account - Basic Settings) to match your actual time zone (or to compensate for the "wrong" server time zone from step 1 if your server is on UTC). 3. At Components - Tags, create a new tag and save it. 4. Edit the tag and look at the created and modified date. 5. Save the tag multiple times. ### Expected result - The creation date should be correct. - The creation date should not be modified by saving the tag. ### Actual result - The creation time is two hours ahead (in case of server time UTC+2) of the current time. - The creation time is increased by two hours on every save. ### System information (as much as possible) - Joomla! 4.0.3 stable - PHP Version 7.3.10 - MySQL 5.6.19-67.0-log - Server: Apache on Linux - Server time: UTC+2 ### Additional comments After the first save, the created time in the database is correctly in UTC. So it appears to be a display issue in the form when you edit the tag. And the value shown there should IMO not be stored in the database when you save the tag again.
Harmageddon 2021-09-25T15:51:16Z[4.1][POC][RFC] Make tinyMCE a true WYSIWYG editor
Pull Request for Issue https://github.com/joomla/joomla-cms/issues/35606 and partially a redo of https://github.com/joomla/joomla-cms/pull/14456
### Summary of Changes
#### Summary, testing instructions, etc will be updated later today or tomorrow (I need to finish the templates for the testing as the current templates are not supporting childs and the changes are available only for those)
This PR is a proposal for 4 changes:
- Use the standard assets override mechanism of Joomla for the tinyMCE skins
- Rework the tinyMCE templates to be in the assets folder of the templates using the new Mode (supporting child templates)
- Introduce `style_formats.json` and `formats.json` to allow tinyMCE to use Bootstrap, Tailwind or whatever other CSS frameworks in the produced HTML
- Templates that support the new mode (child templates) could provide an end point jeditor.php, a copy of their index.php that will return a css representative of the template's styles used
> Use the standard assets override mechanism of Joomla for the tinyMCE skins
So, it seems that I'm trying to revert a very bad implementation of the skins that was introduced by... (drum roll) me back in 2015. Why is wrong? First because it expects the final user to decide on the looks of TinyMCE when that decision is not up to them but it's up to the TEMPLATE. The solution is almost a one line `HTMLHelper::stylesheet()` that will load the provided from tinyMCE skin or will be overrided if in the templates folder `css/plg_editor_tinymce/skins/oxide/...` exists. Simple, elegant, intuitive. Install a backend/frontend template, if it supports custom skin to match the tinyMCE with the rest of the template's design will be used, if not the default is there...
> Rework the tinyMCE templates to be in the assets folder of the templates using the new Mode (supporting child templates)
When Brian reworked the templates part of tinyMCE he used the template's html folder for storing the files under a folder name `tinymce`. This is fine for the existing templates but will not play well with the templates implementing the new mode. The reason is simple the new mode calls for all static assets to be served from the folder `/media/templates/...` so that the actual templates folder will hold only PHP related files and thus could be locked and not being an entry point for the site (Joomla's entry points are: `/index.php`, '/installation/index.php', '/administrator/index.php', '/administrator/components/com_joomlaupdate/update.php', '/media', '/images' and the new one for api `/api/index.php`, meaning that anything else should be locked from direct access to a request). This introduces a minor change, legacy templates will have the tinyMCE templates in the `/templates/templateName/html/tinymce` while the ones supporting the new mode will have to get those files in `/media/templates/site/templateName/html/tinymce`. This would need to be documented when the docs for the child templates will be written.
> Templates that support the new mode (child templates) could provide an end point jeditor.php, a copy of their index.php that will return a css representative of the template's styles used
This might be controversial but the editor.css that tinyMCE is using IMHO should be an exact copy of the front end template CSS. Since Joomla has a pretty nice way for doing this (`?tmpl=something` will load the `something.php` in the template, I build an actual PWA that composes the pages in the service worker just by abusing this https://github.com/dgrammatiko/sloth ) the proposal is to standardize an endpoint for the new mode templates. We don't break anything and we bring WYSIWYG in a opt in way.
sample implementation of jeditor.php
```php
* @license GNU General Public License version 2 or later; see LICENSE.txt
*/
defined('_JEXEC') or die;
use Joomla\CMS\Factory;
use Joomla\CMS\Uri\Uri;
/** @var Joomla\CMS\Document\HtmlDocument $this */
/**
* This endpoint returns the CSS content for the template
*/
$wa = $this->getWebAssetManager();
$mv = $this->getMediaVersion();
$this->setMimeEncoding('text/css');
$this->setCharset('utf-8');
// Template assets path
$templatePath = 'media/templates/site/' . $this->template;
// Color Theme
$paramsColorName = $this->params->get('colorName', 'colors_standard');
$assetColorName = 'theme.' . $paramsColorName;
// Use a font scheme if set in the template style options
$paramsFontScheme = $this->params->get('useFontScheme', false);
$fontStyles = '';
$wa->registerAndUseStyle($assetColorName, $templatePath . '/css/global/' . $paramsColorName . '.css');
if ($paramsFontScheme) {
if (stripos($paramsFontScheme, 'https://') === 0) {
$this->getPreloadManager()->preconnect('https://fonts.googleapis.com/', []);
$this->getPreloadManager()->preconnect('https://fonts.gstatic.com/', []);
$wa->registerAndUseStyle('fontscheme.current', $paramsFontScheme, [], []);
if (preg_match_all('/family=([^?:]*):/i', $paramsFontScheme, $matches) > 0) {
$fontStyles = '--cassy-font-family-body: "' . str_replace('+', ' ', $matches[1][0]) . '", sans-serif;
--cassy-font-family-headings: "' . str_replace('+', ' ', isset($matches[1][1]) ? $matches[1][1] : $matches[1][0]) . '", sans-serif;
--cassy-font-weight-normal: 400;
--cassy-font-weight-headings: 700;';
}
} else {
$wa->registerAndUseStyle('fontscheme.current', $paramsFontScheme, ['version' => 'auto'], []);
}
}
// Enable assets
$wa->useStyle('template.cassy.' . ($this->direction === 'rtl' ? 'rtl' : 'ltr'))
->useStyle('template.active.language')
->useStyle('template.user');
// Get the URLs
$templateCSSUri = $wa->getAsset('style', 'template.cassy.' . ($this->direction === 'rtl' ? 'rtl' : 'ltr'))->getUri();
$activeLanguageCSSUri = $wa->getAsset('style', 'template.active.language')->getUri();
$userCSSUri = $wa->getAsset('style', 'template.user')->getUri();
$fontsCSSUri = $wa->assetExists('style', 'fontscheme.current') ? $wa->getAsset('style', 'fontscheme.current')->getUri() : '';
// Assign the URLs to CSS imports
$templateCSS = ($templateCSSUri !== '') ? '@import url("' . Uri::root() . substr($templateCSSUri, 1) . '?' . $mv . '");' : '';
$activeLanguageCSS = ($activeLanguageCSSUri !== '') ? '@import url("' . Uri::root() . substr($activeLanguageCSSUri, 1) . '?' . $mv . '");' : '';
$userCSS = ($userCSSUri !== '') ? '@import url("' . Uri::root() . substr($userCSSUri, 1) . '?' . $mv . '");' : '';
$fontsCSS = ($fontsCSSUri !== '') ? '@import url("' . $fontsCSSUri . '");' : '';
echo <<style_formats.json
```json
{
"0": {
"title": "Headers",
"items": {
"0": {
"title": "Header 1",
"format": "h1"
},
"1": {
"title": "Header 2",
"format": "h2"
},
"2": {
"title": "Header 3",
"format": "h3"
},
"3": {
"title": "Header 4",
"format": "h4"
},
"4": {
"title": "Header 5",
"format": "h5"
},
"5": {
"title": "Header 6",
"format": "h6"
}
}
},
"1": {
"title": "Inline",
"items": {
"0": {
"title": "Bold",
"icon": "bold",
"format": "bold"
},
"1": {
"title": "Italic",
"icon": "italic",
"format": "italic"
},
"2": {
"title": "Underline",
"icon": "underline",
"format": "underline"
},
"3": {
"title": "Strikethrough",
"icon": "strikethrough",
"format": "strikethrough"
},
"4": {
"title": "Superscript",
"icon": "superscript",
"format": "superscript"
},
"5": {
"title": "Subscript",
"icon": "subscript",
"format": "subscript"
},
"6": {
"title": "Code",
"icon": "code",
"format": "code"
}
}
},
"2": {
"title": "Blocks",
"items": {
"0": {
"title": "paragraph",
"format": "p"
},
"1": {
"title": "Blockquote",
"format": "blockquote"
},
"2": {
"title": "Div",
"format": "div"
},
"3": {
"title": "pre",
"format": "pre"
}
}
},
"3": {
"title": "Alignment",
"items": {
"0": {
"title": "Left",
"icon": "alignleft",
"format": "alignleft"
},
"1": {
"title": "Center",
"icon": "aligncenter",
"format": "aligncenter"
},
"2": {
"title": "Right",
"icon": "alignright",
"format": "alignright"
},
"3": {
"title": "Justify",
"icon": "alignjustify",
"format": "alignjustify"
}
}
}
}
```
formats.json
```json
{
"alignleft": {
"selector": "p,h1,h2,h3,h4,h5,h6,td,th,div,ul,ol,li,table,img",
"classes": "text-start"
},
"aligncenter": {
"selector": "p,h1,h2,h3,h4,h5,h6,td,th,div,ul,ol,li,table,img",
"classes": "text-center"
},
"alignright": {
"selector": "p,h1,h2,h3,h4,h5,h6,td,th,div,ul,ol,li,table,img",
"classes": "text-end"
},
"alignjustify": {
"selector": "p,h1,h2,h3,h4,h5,h6,td,th,div,ul,ol,li,table,img",
"classes": "text-justify"
},
"bold": {
"inline": "span",
"classes": "fw-bold"
},
"italic": {
"inline": "span",
"classes": "fst-italic"
},
"underline": {
"inline": "span",
"classes": "text-decoration-underline",
"exact": "true"
},
"strikethrough": {
"inline": "del",
"classes": "text-decoration-line-through"
}
}
```
[4.0] Broken link to help page when updating Joomla
### Steps to reproduce the issue Install nightly build. Go to `administrator/components/com_joomlaupdate`, make the `extract.php` file readable and hidden (tested on a local host in Windows). Go to Control Panel - System - Joomla Update, select manual package installation, try installing nightly build. It is logical that we will get an error.   Moments: 1. A link to help leads to a broken page (PR https://github.com/joomla/joomla-cms/pull/35659 does not solve the problem), 2. The button needs a small indent, 3. The button has an information icon - unnecessary (considering the link icon). Button indentation is only needed for strictly coded error text. If we get an error according to the lines in the localization file, then due to the P tags, everything is ok.
Kostelano 2021-09-25T10:26:28ZNews