This could conceivably be classed as a feature rather than a bug, but the com_tags component has made my Joomla 3.4 website almost unusuable in com_content backend or frontend editing.
The little predictive tag box basically seems to pre-load the entire list of tags into HTML (see code below). On a site such as mine, with 20,000+ tags that can increase the size of the downloaded page by quite a bit and it now takes half a minute or so to edit any article.
<div class="control-label"><label id="jform_tags-lbl" for="jform_tags" class="hasTooltip" title="<strong>Tags</strong><br />Assign tags to content items. You may select a tag from the pre-defined list or enter your own by typing the name in the field and pressing enter.">
Tags</label></div>
<div class="controls"><select id="jform_tags" name="jform[tags][]" class="span12" multiple>
<option value="999">tag 1</option>
<option value="1000">tag 2</option>
etc
It would be great if com_tags could have an option to Ajaxify this for those with larger tag lists, to query the server directly for matches.
It shouldn't be that much more slow (as with thousands of tags, the browser actually also slows down a lot having to process such a large page and search all those tags dynamically in Javascript).
As described.
Joomla 3.4.4
Running on LAMP etc
Imported large number of tags from ced_tag, which has been abandoned by developer due to Joomla com_tags
Category | ⇒ | Administration Tags |
Labels |
Added:
?
|
Actually ajaxSearch is already implemented, but not used as you've noticed the whole list is preloaded. I had similar issue, with 100,000 tags slowing down the browser. Please test my PR.
Thanks, that looks awesome, will check it out!
For temporary fix you can also:
diff --git a/libraries/cms/form/field/tag.php b/libraries/cms/form/field/tag.php
index 7c8cc04..19cd1fe 100644
--- a/libraries/cms/form/field/tag.php
+++ b/libraries/cms/form/field/tag.php
@@ -140,7 +140,7 @@ class JFormFieldTag extends JFormFieldList
$query->order('a.lft ASC');
// Get the options.
- $db->setQuery($query);
+ $db->setQuery($query, 0, 30);
try
{
and then you get only first 30 tags. After you type 3 chars you get next max 30 tags.
yes, I used that temp fix myself, before finally diagnosing the issue to characters and implementing the proper fix.
Hi CSThomas, your temp fix doesn't really work reliably for me, I think - it loses pre-existing tags when you edit a new article.
Sandrodz's fix sort of works (though it sometimes seems to struggle with finding longer tags or tags with spaces in them when you have a lot of tags on the site). Overall, great job Sandrodz - sorry you're stuck with the Unicode bug - I would help if I could, but Unicode is damn complex...
Try below:
diff --git a/libraries/cms/form/field/tag.php b/libraries/cms/form/field/tag.php
index 7c8cc04..365e231 100644
--- a/libraries/cms/form/field/tag.php
+++ b/libraries/cms/form/field/tag.php
@@ -139,8 +139,17 @@ class JFormFieldTag extends JFormFieldList
$query->order('a.lft ASC');
- // Get the options.
- $db->setQuery($query);
+ if (!empty($this->value) && is_array($this->value)) {
+ $query->where('a.id IN (' . implode(',', $this->value) . ')');
+
+ // Only load selected values.
+ $db->setQuery($query);
+ }
+ else
+ {
+ // Get first 30 options.
+ $db->setQuery($query, 30);
+ }
try
{
Second block 'else' will be use for articles without tags or for tags from popup.
If someone interests I have changed above patch a little.
This is a temporary path for joomla that does not show any tag options in searchtools and in modal batch.
diff --git a/libraries/cms/form/field/tag.php b/libraries/cms/form/field/tag.php
index 7c8cc04..708f57a 100644
--- a/libraries/cms/form/field/tag.php
+++ b/libraries/cms/form/field/tag.php
@@ -139,12 +139,21 @@ class JFormFieldTag extends JFormFieldList
$query->order('a.lft ASC');
- // Get the options.
- $db->setQuery($query);
try
{
- $options = $db->loadObjectList();
+ if (!empty($this->value) && is_array($this->value)) {
+ $query->where('a.id IN (' . implode(',', $this->value) . ')');
+
+ // Only load selected values.
+ $db->setQuery($query);
+ $options = $db->loadObjectList();
+ }
+ else
+ {
+ // Do not load any options - temporary fix.
+ $options = array();
+ }
}
catch (RuntimeException $e)
{
diff --git a/libraries/cms/html/tag.php b/libraries/cms/html/tag.php
index d44636e..16075f6 100644
--- a/libraries/cms/html/tag.php
+++ b/libraries/cms/html/tag.php
@@ -136,7 +136,7 @@ abstract class JHtmlTag
$query->order('a.lft');
$db->setQuery($query);
- $items = $db->loadObjectList();
+ $items = array(); //$db->loadObjectList(); // Temporary fix
// Assemble the list options.
static::$items[$hash] = array();
Status | New | ⇒ | Confirmed |
Closed as this is resolved in #9155 which needs tests
Status | Confirmed | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-08-03 13:16:14 |
Closed_By | ⇒ | brianteeman |
As a temporary fix, I've disabled the com_content tagging functionality in core files by commenting out <!-- < field etc> --> the tags < field > in:
/administrator/components/com_content/models/forms/article.xml
/components/com_content/models/forms/article.xml
The article edit pages now load a lot faster but would obviously prefer not to use a core hack. If there could be a core com_content option to disable that field, for now for those with a lot of tags, that'd be great.