Category: Article

{syntax type="tiki" editor="plain"}
Hello,

this is a problem concerning tikiwiki 2.4.

I have 3 groups: anonymous, registered and admins. After writing an
article it shows up for 'anonymous' and 'registered', exactly as set
in the group permissions. No problem there.

However, I also made several categories. As long as the article
remains uncategorized, everything is fine. But when I assign it to a
category it vanishes from the view of the 'anonymous and 'registered'
groups.
In the categories I have 2 permission options:
'tiki_p_view_categories' and 'tiki_p_admin_categories'. Even if I
assign both permissions to the category, it doesn't make any
difference. The article remains hidden.

Quite ridiculous is, that i have another instalaltion of tiki 2.4, where i can chose out of 5 differrent permissions within the categories.

Cashes have been emptyd.

Hiere is my configuration:

Group Anonymous:
tiki_p_articles_read_heading
tiki_p_list_image_galleries
tiki_p_messages
tiki_p_read_article
tiki_p_search
tiki_p_topic_read
tiki_p_view
tiki_p_view_calendar
tiki_p_view_categories
tiki_p_view_categorized
tiki_p_view_directory
tiki_p_view_events
tiki_p_view_faqs
tiki_p_view_image_gallery

The particular category "in progress" has no group-specific permission (standard / yellow)

The article has category "in progress" assigned.

Anonymous can´t see the article.

Ridiculous is, that if i try to assign a specific permission to the category "in progress", just the following two permissions are available for selection:

tiki_p_view_categories
tiki_p_admin_categories

Even if i assign those to the category for anonymous, they are not able to see the article.

{syntax type="tiki" editor="plain"}
There is no option in the admin topics to display the last date an article was updated (modified).
This is very common for articles or news to show this information.

I believe we have it stored somewhere.
It would be nice to add this option at : tiki-article_types.php

You can use Tiki articles in multilingual website having article for several language.
The usual process is to create a main article (default language) then create other articles with different language and assign them as translation of the previous article.
Article => Edit => Advanced, Attach existing article ID as translation

You have to insert the ID of the article and that really not user friendly.

You should be able to retrieve articles by name in a select.

---

On second thought...

If wed really like to improve we could reuse the same interface/system we have with wiki pages (translation) as it is working fine is much better (proposing translation if missing and displaying set of translated documents) and will be better for UX (consistency).
I just wonder if it worth the investment.

On a quite big and several time upgraded Tiki all unified-index errors were running without errors.
Since a few month I see an error for each article that has the field source filled with an URL.

2022-11-14T07:55:37+00:00 INFO (6): addDocument article 470 {"memoryUsage":"38.5 MiB"}
2022-11-14T07:55:37+00:00 ERR (3): NOTICE: Trying to access array offset on value of type bool {"code":null,"file":"/var/www/vhosts/xxxx/xxxx/lib/core/Search/ContentSource/ArticleSource.php","line":53}
2022-11-14T07:55:37+00:00 ERR (3): NOTICE: Trying to access array offset on value of type bool {"code":null,"file":"/var/www/vhosts/xxxx/xxxx/lib/core/Search/ContentSource/ArticleSource.php","line":56}


{CODE(caption="lib/core/Search/ContentSource/ArticleSource.php, lines 47:59")}
$rss_relations = TikiLib::lib('relation')->get_object_ids_with_relations_from('article', $objectId, 'tiki.rss.source');
$sitetitle = '';
$siteurl = '';
if ($rss_relations) {
$rssId = reset($rss_relations);
$rssModule = TikiLib::lib('rss')->get_rss_module($rssId);
if ($rssModule['sitetitle']) {
$sitetitle = $rssModule['sitetitle'];
}
if ($rssModule['siteurl']) {
$siteurl = $rssModule['siteurl'];
}
}
{CODE}

On article you can set the image, Own Image and you can set Read Article, Maximum dimensions of custom image in view mode, Width.

If this field had a value and you empty it and save you the article may display a random image.
This because reseting to an empty value broke the linkeage between the article and the previously uploaded image.

It is happening randomly (happened to me twice)

On next we have an article; https://next.tiki.org/article497-Biggest-Tiki-Release-Ever-Tiki-25
''To be sure I can see what is happening with the maximum width available I disabled fixed width''

As you can see on the video, the image displayed width is 555px. (fixed with disabled + 27inch screen)

On article settings (https://next.tiki.org/tiki-edit_article.php?articleId=497#content-edit_article1-4), Read Article: Maximum dimensions of custom image in view mode, Width = 720px.
Visibly (fill-width with a very wide scree) this is not applied.

Demonstrated on next.t.o
{mediaplayer src="display2131"}

Normally the "Read more" link of an article (displaying on the articles main page) links to the article's individual page. (From [https://doc.tiki.org/Article-User#Editing_or_Submitting_Articles]: "Source (url) - If appropriate or useful, a reference link can be specified. This displays at the end of the article." ) But in trunk now, if you add a "Source" URL for the article, which is supposed to (and previously did) link to an external URL, then the "Read more" link somehow gets that "Source" URL information.

For example, if my article is based on some announcement from the United Nations, I might put http://www.un.org/ in the Source text field. But of course I still want "Read more" to link to the body of my article. However, now "Read more" links to the United Nations website.

Also the article title, which on the view-articles page is normally a link to the article's individual page, takes on the "Source" URL as well.

When you sort a listing of articles, you can have the results sorted on the size of the articles. But the result is illogical, which is more visible when sorting descending, but in principle ascending is affected as well: The sorting is done NOT numerical (which you would expect on a numerical value like size), but by string representation.

The result is e.g. that "456 bytes" is being considered larger than "1.2 kBytes"...

If you go to articles home, and have your articles listed, you can have the list sorted by clicking on the column header. By clicking that again, you can change sorting direction (ascending/descending).

This doesn't work with the ID of articles. They are always listed ascending. However, the small arrow indicating the order DOES change to descending, but the listing isn't altered at all.

Clicking on the title of an article should be like "read more", like for the image. Seems more intuitive to me.

Please see:
http://tikiwiki.org/tiki-view_articles.php

And imagine clicking on the title to be taken to:
http://tikiwiki.org/tiki-read_article.php?articleId=166

This is an easy fix.

In the article actions button group, there's an i18n icon and a chevron, to click to open the translation management dropdown and the article actions dropdown, respectively. But in trunk now, the translation management dropdown opens when both are clicked. The article actions dropdown (containing edit link, etc.) doesn't display at all.

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

References to the external_link.gif image don't work in articles when in mobile mode, and TW is installed in a subdirectory. The reference points to /img/icons/external_link.gif instead.

Example: http://www.vic-fontaine.com/forum/tiki-read_article.php?mode=mobile&articleId=1

Test user/password: smarty

Hello,
Updating an article, there is a problem of images not saved when the Tiki interface is in French, image disappear from the article.

The problem do not occur when the interface is in English or other language.

I have fixed the problem and the solution I found is on your forum, ((https://tiki.org/tiki-view_forum_thread.php?forumId=6&threadId=76791&comzone=show|here))
https://tiki.org/tiki-view_forum_thread.php?forumId=6&threadId=76791&comzone=show

Sincerely
Patrice

As admin I view _article_, then click on the "Multilingual globe". This brings the translation page. At the bottom I select new language and press "Change language" button. All I receive is "Page not found" error.

The "Change language for this page" form fails when it's applied to an Article.

{syntax type="tiki" editor="plain"}
When editing a Wiki Page (properties) or an Article (classification), if you use the Tiki tags (freetags) you will see a "Tags" field with the list of the most popular or last used tags.

Normally when you click on a tag, it is added to the field.
This is not working anymore.

Tiki Wiki is a content management system. And it can be used to distribute text (but also images, music etc.) to the world.

In Germany, there is no copyright as it exists in the US. Instead, authors have inalienable rights to their works (which cannot be sold or transferred) and for the usage royalties apply.

There is a system of collecting those royalties like VG Wort. If a publishing house reprints text that are declared by the author, publishers pay to VG Wort, they pool all those royalties and pay their members on the basis of the amount published by an author.

For several years now, VG Wort has a system for online texts (METIS). In order to participate, web sites must include "count marks" together with the texts. The author requests (personal) count pixels from VG Wort, and the website must be programmed so that it deliveres those pixels.

In essence, such a count pixel is just an img loaded from VG Wort's servers, a transparent GIF with 1x1 pixels in size. The author gets them in form of HTML lines like this, for example:

{CODE(Colors="TikI")}
<img src="http://vg08.met.vgwort.de/na/e1c16c290fc545d8809d5990b2295aa6" width="1" height="1" alt="">
{CODE}

There is one specific pixel per text, not per author.

It would make things vastly easier if Tiki could automate the process. Pixels get handed out to authors either als a PDF or as a spreadsheet table (CSV...).

A system could be devised where a Tiki user would upload such a CSV, and a plugin could be integrated into a content page (article or wiki). Less sophisticated, the user would indicate a "text ID" to identify the text. A more sophisticated system would, when the plugin gets called, look up if the calling content already has a pixel assigned, and if not, assign one and track the relationship of pixels with contents and then playout the respective pixel alongside with the content.

This system could also inform the user if the amount of pixels is less than the amount needed by current online content and create nice reports :-)

Systems for collecting royalties ("copyright collectives") exist in every country, so this would not only be useful for German Tiki users, but for practically everyone that shells out copyrighted texts larger than 2K...

https://en.wikipedia.org/wiki/Copyright_collective

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... :(

Creator can edit option selected in article type not filtered on for edit permission in edit_article and edit_submission. Author's submissions once validated cannot be edited by their authors.

At google search console (https://search.google.com/search-console/sitemaps) my sitemap (using https://bernardsfez.com/storage/public/sitemap-index.xml) is submitted via the console.php command (using the Tiki scheduler).

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

If I click on the corresponding row it open a detailed table where I see that Google fetched 2 XML and that fetching my articles XML it produce 1 error.

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

When I click on it to see the details I see error about the lasted date.

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

And when I look at https://bernardsfez.com/storage/public/articles.xml the dates are all wrong.
It seems to prevent Google to index my articles.
When I index one by one articles using https://search.google.com/search-console/inspect (when a page is not indexed I have an option to index it) It work just fine with the right date.

I also checked at tiki.org and I see the same errors: https://tiki.org/storage/public/articles.xml

{FADE(label="XML where we can see the date errors" icon="y")}

<!-- Generated by https://git.io/phpseo -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/%25D7%25AA%25D7%2595%25D7%259B%25D7%25A0%25D7%2594-%25D7%259E%25D7%25A7%25D7%2595%25D7%2595%25D7%259F-%25D7%259C%25D7%25A0%25D7%2599%25D7%2594%25D7%2595%25D7%259C-%25D7%25A6%25D7%2594%25D7%25A8%25D7%2595%25D7%259F-%25D7%2597%25D7%2595%25D7%2592%25D7%2599%25D7%259D-%25D7%2595%25D7%2592%25D7%25A0%25D7%2599-%25D7%2599%25D7%259C%25D7%2593%25D7%2599%25D7%259D</loc>
<priority>0.6</priority>
<changefreq>weekly</changefreq>
~~#F00:<lastmod>6773-12-06T16:34:41+02:00</lastmod>~~
</url>
<url>
...
~~#F00:<lastmod>1970-01-01T02:00:00+02:00</lastmod>~~
</url>
<url>
...
~~#F00:<lastmod>1970-01-01T02:00:00+02:00</lastmod>~~
</url>
<url>
...
~~#F00:<lastmod>5887-12-06T16:05:59+02:00</lastmod>~~
</url>
<url>
...
~~#F00:<lastmod>1970-01-01T02:00:00+02:00</lastmod>~~
</url>
<url>

{FADE}

{syntax type="tiki" editor="plain"}
The styles of the "button" of the date picker (or whatever it's called - the place you click to display the selector for the date and time) such as the font and colors are set dynamically to match the theme being used. This works for the themes in the themes directory, but this doesn't work completely for custom themes.

For example, I have a custom light-on-dark theme with a body background color of #0c0d16 (almost black) and a .form-control background color of #343a40 (also very dark), but the background color of the date picker's "button" (~np~div.dp__main dp__theme_light~/np~) is very light so clearly isn't getting the background color information correctly from the theme stylesheet. In a non-custom dark theme like Slate, I can see the button display with a light background for an instant and then get the correct dark background color to match the Slate theme, but for custom themes this switch doesn't happen, in my experience.

On the other hand, the date picker is using the right font, as specified by the custom theme, so there's partial success here.

I tested with the Switch Color Mode not active and with it active and set to both light and dark and the date picker button background was never correct. A workaround would be to add a CSS rule to the custom theme to correct the background color, but it would be nice if it worked automatically as it does for the themes in the themes directory.

Actually, now that I look again, it appears that the background color for the popup (with date and time selectors) isn't correct for non-custom themes, either. Using the Slate theme, which has a dark background color, the date picker popup has a light background with light text. This bad contrast is maybe due to the correct text color but wrong background color being used.

Also, the selector and popup backgrounds aren't sensitive to Color Mode switching.

Hopefully the same fix for these issues will work for both custom and standard themes.

The default size of article images is the least little bit too high in my view.

The explanation given to the admin reminds the admin "Maximum file size for an article image. Article images are stored in the database so it should remain low". And after stating that, the default is 500.000. Kilobytes :-) That's 500 MBytes for one single image. I wonder what MySQL thinks about a blob of 500 meg... And imagine a backup of that DB in .sql format... :-)

{CODE(Colors="Tiki")}
'article_image_file_size_max' => [
'name' => tra('Article image maximum file size'),
'description' => tra('Maximum file size for an article image. Article images are stored in the database so it should remain low.'),
'type' => 'text',
'size' => '10',
'filter' => 'digits',
'units' => tra('kilobytes'),
'default' => 500000,
],
{CODE}

Updated from 9.3 to 13.1, now article modules do not display filtered by category when article assigned to the specified category.

We use module articles for listing articles. Articles are categorized in different categories. Listing is in the right column next to the article and list the titles of articles from the same category as displayed article.
{img fileId="980" thumb="y" rel="box[g]"}
In version 13.1 do not function the parametr Category in visibility settings of module.
{img fileId="981" thumb="y" rel="box[g]"}
{img fileId="982" thumb="y" rel="box[g]"}
If is the module configured as shown in figures, the module is not displayed next to the article.
In previous version this parametr works fine.

for users with tiki_p_wiki_view_comments perm only, it displays the ~np~[comment]~/np~ link on the wiki page bar even when no comments there yet to read, so clicking it does literally nothing...