Category: Category

Show page title on per page edit, if set to off, turns off page title as well as page category.
One setting effecting two features! It should be normal behaviour to see page category without page title.

{syntax type="tiki" editor="plain"}
Watch Module must be turned on.
Category module must be tuned on.
Article Module must be turned on.

If I create a new Article and assign it to a category that is watched by me, I should get a notifcation that a new object has entered the category. By I don´t get a notification.

I encountered this problem while I was working on the new report feature because I didn´t get an entry in the report too.

The possible Bug is located at the update_object_categories function in categlib.php (Line 1491) in the $categories variable.
$categories contains all new Categorie-ID´s of an object. So if I assign an article to a category, $categories should contain the ID of the category. No problem so far. The problem is, that each ID has a slash behind the last digit.

{CODE(colors="php")}print_r($categories);
die();
{CODE}

at the third line of the function gives

{CODE(colors="php")}Array
(
[0] => 2/
){CODE}

I think the slash is wrong.

ex.: rollback and view source actions appear but then, there is an error when trying to use

When sorting by category tracker field, the sort is on the category ID as text. Example:
11
110
12
13
14
141
15
The sorting should be just as it is on the ‘browse categories’ page – as a tree. The listing is alphabetical at each level, and all child items are listed before the next item at the current level.

Please see:
http://sourceforge.net/mailarchive/forum.php?thread_id=10026369&forum_id=12569

In tiki-browse_gallery.php, there is Sort Images by [ Name | Date | Hits | User | Size ] so robots can think these are all different pages

Hello there,

I just upgraded our TikiWiki from 1.9.11 to 2.0. I am really happy with 2.0 by the way! Way to go!

Everything went well during the upgrade, except that I get this error message every time I try to administer our categories:

http://dev.tikiwiki.org/tiki-browse_image.php?imageId=52

Everything else seems to have upgraded just fine. Yes I did follow the instructions during the tiki-install.php and run the 1.8 -> 1.9 SQL script prior to the 1.9 -> 2.0 SQL script. I noticed that there were around 150 SQL "errors" during the upgrade script, but I thought nothing of this.

Thanks a million!
Russ
rfruhwirth2@unl.edu

I am using Tiki 24.2 on a fresh install on CentOS 8, MariaDB 10.3.28 (InnoDB) and on client side Ubuntu 22.04 with Firefox 107.0.

Just added a new category, works fine. Added a subcategory. This subcategory is there (showing in various menus as "category::subcategory" where i have to select a category), but it is not showing at all when just listing the categories. In Tiki 21.5, categories with subcategories are shown with a little triangle left to them, so they can be opened to show the subcategories. In 24.2 this triangle is not shown at all, I cannot access the subcategory at all.

I noticed a link text beneith the search form "show subcategories", but it does exactly nothing.

Easiest fix would be to revert behaviour to what it was in Tiki 21.5 as it was working fine.

{syntax type="tiki" editor="plain"}
When using "Theme control" together with a Category, the *.tpl files in templates/styles/{mytheme}/ are not considered for the pages attached to the category.

To see this, create a testcategory and a testpage. Then use "Theme control" and configure a theme having some *.tpl files in templates/styles/{mytheme}/ to be used for the testcategory.

Go to the testpage and it will show in the style. Now try to change one of the *.tpl files. The changes do not take effect.

Note that this is not about emptying the cache.

You can try and use mytheme as main theme and the one you used previously as main theme as "Theme controlled" one. You will now be able to edit the templates/sytles/{mystyle}/ files with the edits being picked up, but now changes to files in the former maintemplate cease to be considered.

The application of style templates by category is nice, but it would be nicer if there was an option to have the template apply to all current and future children of the category.

test4 with the "status ticket" prefilled with "closed - cancelled", as shown by default

{syntax type="tiki" editor="plain"}
When you duplicate a Wiki Page you have 2 additional options:
* Duplicate categories
* Duplicate tags

Both never worked for me as far as I can recall.
When I duplicate a page that are categorized and have tags the new page won't have them.

It should be fixed OR even removed as no one seems to use this (never worked for me since Tiki24 or even more)

It is giving a bad image of Tiki.

!The specialization of categories in profiles : major consequence

!!Nature of the problem

Everybody who have developed tikiwiki application that during data structuring and at the end of development (if it exist, not in project management) any category can't be applied to any object.

So if we try an interpretation of this fact it is because the development of categories is a way to structure either a metabase or an implicit complement of database on the objects of tiki.

In project management we will have to connect to new objects and sometimes to create links with external objects (can be defined by URLs). This because the object that are managed into a project can be separated into two classes :
*the objects that are tiki objects and
*the objects that are external (as CAD draw, all physical objects and their definitions managed externally): these object must have an "image" into tiki like a map and his corresponding land, mainly a wiki text with the definition of the object. But in fact others objects can be associated to these external object. So they can be simply a category with a link to a new objects for tiki (see UMLAP meta model that I presents). This new objects is simply able to reference an external object (quite like an URL).

So either in simple tikiwiki application or with project management, categories are in fact quickly linked to some types of objects.

A category will define a way to hierarchically organize blogs or forums, it will be only associated to the corresponding object.
Another for example with a root "Subjects" can classify structures, wiki pages, blogs, calendars etc...

The development of the application or profile then will be associated with a specialization of categories.

!!What's to do to implement this new feature ?
*Add to the definition of a category a multi-select box which allows to define the objects classes to which the category can be linked
*Link a category to a specialized wiki structure which contains the definitions of the categories (the wiki structure is automatically a replication of the category structure)
*For the display of the panel used to define the classification of an object into the categories, the displayed categories must be associated with the class of the object.
*Quite automatically when the list of objects which are associated to the same category is displayed it will contain only the classes associated to the category.

It is not very load as development but I do believe a great enhancement to clarify categories management and use.

Trebly

Please see:
http://phplayersmenu.sourceforge.net/example-treemenu.php

With a view source, you will notice
class="phplmselected"


How can we add this to Tiki?


Menu tree built from categories?

Or if the menu compares with current URL? and puts class="phplmselected" if it's a match?

the page tiki-admin_categories.php page don't display
at all. The internet explorer page 'The page connot be
displayed' is shown.
When I switch off the gzip compression of output in the
general admin setting, the tiki-admin_categories.php
displays an empty page (modules and menu are
present but not the core page).
What is most interesting is that is broken on a
production linux server running PHP Version 4.3.0 and
works on wamp running PHP5 under windows... could
someone help me?

theme: TheNews
common problem when badly closed tags appear in the generated page source
left/right modules colums go down, cannot click to edit the category then

{syntax type="tiki" editor="plain"}
I have noticed that if I browse to tiki-browse_categories.php I have to wait an order of magnitude longer for the page to load compared to any other tiki system page. There are about 400 categories in the database.

If this delay is most visible when viewing tiki-browse_categories.php, is there a possibility that fractions of that delay are spread across the rest of the website depending on how many categories are associated with each wiki page?

If so have I found a bottle-neck that could be optimised?

Hi,

First a warning: I am new here... and new to linux...

I installed tikiwiki and while configuring the categories and user rights I got the Message

Template Error: setRoot: . is not a directory.

It happend calling the page

tiki-browse_categories.php

and it happens with all users I configured, even the adminuser.

Any ideas?

Thanks a lot,

Christoph

for exemple:
http://dev.tikiwiki.org/tiki-categpermissions.php?categId=2

tiki-list_object_permissions.php is fantastic

It lets me review any permissions received from category, and individual perms.


Some enhancements:
* Link to the category perm interface so I may adjust the perms
** As of 4.0, I need to check each category to see why the perms are applied
* Type group is missing (permissions ''about'' groups)

All optional via tiki-admin.php?page=wiki

Language (if multilingual is activated)

Category (if feature turned on)

+ add filter by language and filter by category like we have at tiki-list_articles.php

tiki-view_forum_thread.php does not check for category perms

CVS HEAD 1.9.x Revision 1.82

In TikiWiki 1.9.11 When a Wiki page is included within another page, the "tiki_p_view_categories" permission does not seem to apply. My investigation was as follows:

1. I assigned "tiki_p_view_categories" to a Category A, and specified Group A.
2. I logged as User B, from Group B
3. I copied and pasted the URL of the restricted page, and received a "Permission denied you cannot view this page" message (GOOD)
4. I searched for the page and it did not appear in the Search Results (GOOD)
5. When I accessed a page that included the page via the {INCLUDE(page=>CategoryA_Page)}{INCLUDE} plugin, the content did appear. (BAD)

The Group+Category permissions should work exactly as they do for Group+Page permissions – namely, a page never appears to a user outside the group, whether accessed directly, or via inclusion through the {INCLUDE(page=>CategoryA_Page)}{INCLUDE} plugin.

{syntax type="tiki" editor="plain"}
Tracker Field Category just displays one level beneath parentID which I would call a bug as it blows up tracker forms when having a lot of categories with multiple sub-levels to chose from. Addionaly it is (pretty tracker example) intended not to allow editing of (wiki tpl) pages so categories have to be applied through the tracker form itself. In my case I have approx. 250 Categories.

It works nicely for text fields. It would be very useful for categories too.


Probably related: categories don't appear in plugin trackerlist

__Solved - PHP 8 is not yet supported by Tiki and is planned to become supported in Tiki25.__
__Tiki22, Tiki23 and Tiki24 LTS require min and max version PHP7.4 __

When I run a new installation on a quite decent shared hosting (all-inkl.com) with __PHP8.0__ (or __PHP8.1__) and same time __active feature Category__, then it is not possible to create a new tracker.
The modal starts to open, but disappears before it is folded out.
For a glimpse of a second it is possible to see the title of the modal which includes an error message.
The error message is in red color as following:
__Error loading content.__

''Either'' deactivating __Category__ ''or'' switching __PHP from 8.0 to 7.4__ allows me create a new tracker.

__Conclusion:__
There is a bug affecting Trackers, that occurs in combination of active Category and PHP8.x

What I did:

1. test the bug in a show2 instance
__result:__ bug not reproduced ... tracker created successfully

2. deactivate features on the devs local website step by step to find out the conflict
__result:__ bug on local instance, not on show2.tiki.org, narrowed down to Category feature

(:question:) Think about possible differences of local instance and show2 instance ...
(:idea:) Git vs SVN? http vs https? PHP version!

3. check PHP - local was on PHP8.0 - tried PHP7.4 and PHP8.1
__result:__ the bug disappears, when I set another subdomain and run the very same website on PHP7.4 whilst the bug consists on PHP8.1.