Category: Category

I have a site where saving (or cancelling editing) a wiki page wasn't working, you just get the same tiki-editpage.php back... After a lot of searching i found it was due to a php.ini setting called -+max_input_vars+- which defaults to 1000. And this site now has 1016 categories! (:eek:)

My proposal is to make a better category picker which can use a hidden input to contain a comma separated list of the category id's selected as on single input, instead of having 1016 individual checkboxes on the form.

So let's find a nice, hierarchical picker to do this, maybe a Vue JS one? Or maybe this should be an extension of -+object_selector_multi+-

Notice: Undefined variable: modcatlist in modules/mod-change_category.php on line 80

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

{syntax type="markdown" editor="plain"}
If I create a category with default text editing setting all is fine.

If I enable Markdown and create a category the name and the description will display the markdown syntax that will cause cascading problem as the browser tab may display this as the tab title.

Editing in the db and removing the content fixes the issue.

{img fileId="3260" thumb="box"}

If you add a colon ":" in a category name it will return a 500 and broke the Tiki.
IE : "Archive : Pouf"

See the instance where I tried it : http://bsfez-11581-7962.show2.tikiwiki.org

Steps to reproduce:
#Go to https://tiki.org/News
#Go to https://tiki.org/article452-Tiki-18-1-has-been-released-fixes-and-security-update
#Click "New Article"
#Enter a TEST title, Classification > Topic Releases and Patches, Publication > __uncheck the "Published" checkbox!__
#Click the "Save" button

You get switched back to default perspective. When you switch back to the first tab "Content" you see the form content is gone and the rest of the tabs got reset to the defaults as when you start editing new article... :(

This will make upgrades easier as people won't have to worry about overwriting their enhancements,

Multilingual categories need translations and doing by FTP is not fun.

Related:
[tiki-view_tracker_item.php?itemId=485] -> This is suboptimal


Support.mozilla.com has need for this as well.
https://bugzilla.mozilla.org/show_bug.cgi?id=488728

In 3.0, language/*/custom.php can be managed by the web interface.

Next step is to have this in a wiki page

Using the setting 'Default Category' on the admin page of a group doesn't work.
According to the label it should: Default category assigned to uncategorized objects edited by a user with this default group.

How to reproduce:
- Changing the Default Category on Group X from none to category Y.
- Creating a new wiki page by a user that is (only, except the build in Registered group) part of Group Y.
- Viewing the tab 'Categories' on the edit wiki page
- There is no category selected...

This means the users can set an incorrect category to a page, so they don't have access after saving the page.

I have reproduced it on the demo environment as the 'show' environment has a problem with Composer not installed:
https://demo.tiki.org/18x/tiki-editpage.php?page=Test123&quickedit=Create+Page#contenttabs_editpage-2
Login with
User: User_Test
passw: User_Test

{syntax type="tiki" editor="plain"}
In group settings, there is an option to set a default category for any uncategorized objects edited by the object. This feature does not work.

It is too difficult now to watch categories (but the feature works well).

Please see: ((Category Watch DogFood))


on ((SUMO)): [https://bugzilla.mozilla.org/show_bug.cgi?id=498001|Improve UI and feedback for watching categories to say you'll be e-mailed and offer easy way to turn off]

Nelson assigned a ticket to mani and categories were lost
http://dev.tiki.org/tiki-tracker_view_history.php?itemId=4704

selection of category fields in tracker items is lost when you re-edit the item.

inserting tracker items in dev.tw.o works fine (through ((Report a bug)) and directly through [tracker5]. However, editing those bug reports seems not to be allowed as expected, because selection to the category fields is lost when you edit the tracker item again to update it, and thus, since one of them is compulsory, the changes can not be saved if you don't re-select the category checkboxes.

Tiki already shows the category and/or category path when listing wiki pages. I would like to also display the category information in search results.

This would help end-users determine the relevancy of the search result.

The behavior for browsing categories has changed, and not to my liking. If this was not intentional, then it is a regression (as I've listed it). If this was intended, then please consider this a "wish" to restore the old behavior or (perhaps better yet) provide a plugin that allows me to control the display.

I have two versions available for viewing. They are not show.tiki.org, but they should do for demonstration.

11.2-
http://www.hrsms.org/home/cat74?deep=on&type=wiki+page&sort_mode=name_asc

9.2-
http://www.hrsms.org/home9/cat74?deep=on&type=wiki+page&sort_mode=name_asc

I like that in 9.2 it only shows the current category, and without watch links.

In 11.2, all categories are shown, with watch links (which in my opinion just add clutter to the page), and the category listing is expanded to the last viewed, not the current. To see this:
a) Browse categories on this site
b) Expand "How To-->Hulls"
c) On left menu, select "Models-->By Nationality"
d) Note that the results displayed are for nationality, but the category listing is still expanded to "how to--> hulls". Confusing to the viewer.
e) Change current URL from ..\home\.. to ..\home9\.. to see how "nationalities" looked in the old version. I much, much, much prefer this way.

I tried using PluginCategory for the same purpose, but I could not get the desired results. Indeed, I'm not even certain I get the results that should be expected. Based on my understanding of the parameters, I would expect the categories AND sub-categories to be displayed, and the results split when the category changes. That does not happen. You can see that here:
http://www.hrsms.org/home/Models

{CODE()}{category id="4" types="wiki" sort="name_asc" split="y" sub="y" showdescription="y" showname="y" showtype="n" one="y" showlinks="y" categoryshowlink="y" maxRecords="1000" showTitle="n"}{CODE}

{syntax type="tiki" editor="plain"}
This is annoying!

Workaround is to remember to pick category again when you save.

These settings:
Categories
Show Category Path
Show Category Objects
here: tiki-admin.php?page=features

And this one:
Ignore category viewing restrictions :
tiki-admin.php?page=search

Should be added to a new admin tab "category":
tiki-admin.php?page=category

IMHO, it is OK for options/settings to be in more than one admin panel, if relevant to both.

{syntax type="tiki" editor="plain"}
If you filter on a category field in trackers, you cannot edit any viewed tracker items. The system returns a SQL error because filterfield is set, and filtervalue is null. If you filter on other fields, you can save, with no errors.

I have traced the problem to the calling of trklib->list_items (this holds the query that fails). This function is used to call and order the other tracker items for easy pagination of the filtered tracker items after a save.

However, the real problem is that $_REQUST['filtervalue'] and $tryfiltervalue get lost in tiki-view_tracker_item.php when the save submit action is done on the form. Other URL query parameters appear to be stored as hidden fields on save action in tiki-view_tracker_item.

For whatever reason, non-array filtervalue fields (e.g. plain text fields) are remembered and thus the pagination and call to list_items works just fine.

However, when there is an array filtervalue (like there is with category fields), then filtervalue gets lost on the save action, and the save fails on a malformed query.

You can't assign an empty category to the tracker category type field. This would come very handy in connection with the Autocheck-feature I RFEd before..
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=246&show=view&status=op&trackerId=5&sort_mode=f_41_desc

Top
|
|---1 Stuff
|
|---2 More Stuff

If you for example assign parentId=1, then you don't get a Checkbox with Stuff, but you get two boxes with Stuff and More Stuff - Tiki jumps back to the higher level, that's not empty.

You can batch upload a category tree.
*tiki-admin_categories.php#content_admin_categories1-2

You cannot export a category tree.

It would be nice to be able to export your entire category tree.
*Or specific branches of a tree.

We have a nice profile to setup all countries in a Category branch.
*If we had a way to export branches, then you would not need to setup profiles to import them.
**t.o could possibly have a repository of category branches people have created and shared.

Only set the Easy to solve? value at 5 because I really have no idea how hard it would be to do.
*Please disregard this value if you are more knowledgeable about the program.
*If there are existing functions that could easily be modified, this might be a really quick fix.

In many cases, have extra structured fields in wiki pages would come in handy. Ex.: a glossary of terms may need a field for noun, adjective, etc.

Categories and tags are not in the version history, and it would be clunky anyway.

((doc:Pretty trackers)) are awesome when it's a data centric context. But when the structure emerges from the wiki, it's better to have extra fields to wiki pages.

{syntax type="tiki" editor="plain"}
After being uploaded it should be possible to categorise ALL files of a Gallery or to select several and categorise them with 1 or 2 clicks.

You can categorise a gallery BUT it will not apply the category change to the inner files of the gallery.
When you are in the gallery you can view the files in the gallery and can select several files to move them, delete them, etc but not to categorise them. This is really missing (after moving image gallery or reorganising a Tiki) as you have to edit one by one the file properties and categorise it.

On the Category Admin side there is not easy way to do this either. You can categorise a Gallery but not the files in it.
You have to search categorise each object one by one. Not humanly doable....

This bug occurs when using multiple workspaces, where each have a perspective with a category Jail.

Consider each workspace to have a main file folder (that belongs to it`s main category, and is only acessed by a certain group when it enters the workspace).
If you upload a file with the normal way, it will acquire the category by the autocategoriation pref.
But if you use the drag and drop feature, it will have no category, and will become invisible to the users, even if is inside the main group folder (because it has no category, and the category jail pref is on)

Show instance: http://fvtorres-11800-5950.show.tikiwiki.org/
User: admin
Pass: 12345

Chose a non-default workspace:
{img fileId="1064" thumb="box"}

Open File Gallery and upload a file:
{img fileId="1065" thumb="box"}

Choose the file and see that the checkbox marking the category corresponding to the workspace is checked:
{img fileId="1066" thumb="box"}

The file is uploaded:
{img fileId="1067" thumb="box"}

Browse the file gallery - it is empty, where did the file go?
{img fileId="1068" thumb="box"}

Open the file gallert from the default perspective (workspace), the file is shown, thus, it was uploaded:
{img fileId="1069" thumb="box"}

Let's see its properties:
{img fileId="1070" thumb="box"}

It doesn't belong to the category it was said to belong during the upload:
{img fileId="1071" thumb="box"}

We add it to the category that we intended it to belong to:
{img fileId="1072" thumb="box"}

We switch back to the desired workspace, open the file gallery, our file is there:
{img fileId="1073" thumb="box"}

__Very low usability!__

On tiki it is possible to categorize a File Gallery but this is not recursive and does not includes all children inside the gallery. It is require to change category for each file one by one from the File Galleries or to use Category Administration to slide one by one files (without real knowledge of what is their parent file gallery.

We should have a way to categorize a file gallery including all _it's_ files / children.

Discussion related: https://tiki.org/forumthread79150-Is-there-a-way-to-categorize-all-the-children-of-a-file-gallery