私の 前の投稿 に続いて、設定コンポーネントの負荷を軽くしようとしています。ユーザーグループの大部分は登録済みユーザーグループの子であり、同じ権限を継承しているため、com_configにロードする必要はありません。
回避策として、コアコードをハッキングすることでそれらを除外する方法を探しています。 getUserGroups()
関数のwhereで試してみました:_/administrator/components/com_config/models/fields/filters.php
_、および
_`/administrator/components/com_config/model/fields/filters.php` .
_
関数は次のようになりました:
_protected function getUserGroups()
{
// Get a database object.
$db = JFactory::getDBO();
// Get the user groups from the database.
$query = $db->getQuery(true);
$query->select('a.id AS value, a.title AS text, COUNT(DISTINCT b.id) AS level');
$query->from('#__usergroups AS a');
$query->join('LEFT', '#__usergroups AS b on a.lft > b.lft AND a.rgt < b.rgt');
$query->where('a.parent_id != 2');
$query->group('a.id, a.title, a.lft');
$query->order('a.lft ASC');
$db->setQuery($query);
$options = $db->loadObjectList();
return $options;
}
_
しかし、これらの変更は、com_configのグループ読み込みに影響を与えないようです。 _/libraries/joomla/form/fields/rules.php
_でも同じ変更を行いましたが、これによりこれらのグループが除外されます。しかし、これはJoomlaが目にするu.groupsでグローバルに機能し、それらのu.groupsを表示するために必要なコンポーネントの一部に影響を与える可能性があることを恐れています。
最初に、com_config getUsergroups()
関数をハックしても効果がないのはなぜですか?そこでフィルタリングを行うにはどうすればよいですか?第2に、私の第2の変更により、これらのu.groupsがJoomlaのどこからでも非表示になることを考慮するのは正しいことですか?
私は内部のrules.phpをハッキングしてしまいました:
/libraries/joomla/form/fields/rules.php
ファイル内に記載されているので、これは特定のアセットのグループに権限を割り当てるためのフォームクラスです。
Com_configのgetUserGroups()
は、権限グループのロードには何もしないようですが、(明らかに)フィルターセクションのグループに使用されます。
Com_usersをチェックインしても、まだ追加のユーザーグループが表示され、おそらく他のニーズに必要なアクセス権がまだあるでしょう。
したがって、私の場合、Joomlaがより優れたソリューションを提供するまで、この小さなコアハックは私を動かし続けます。もちろん、更新することはできませんので、手動で再実行する必要があります。