Category: Article

WAS TICKET 6651 (I can't find it anymore) {sign user="Bsfez" datetime="2018-08-19T10:00:56+00:00"}

Since update 18.0 article generator cannot produce articles anymore. It was (and should be able) to built articles from external feeds.

Demonstrated : http://arthurt-11797-6651.show.tikiwiki.org/
I reproduce on the show and I confirm the regression. {sign user="Bsfez" datetime="2018-08-19T10:00:56+00:00"}

This can be viewed both as a bug report or a feature request:

The logic for article images breaks standard Tiki admin logic in that you cannot (!) use images from the file galleries. You have to upload them separately into where ever they get stored (unknown), stripping users of the ability to centralize image storage and scaling images by demand. This also means that the user must use a local image manipulation tool for scaling...

This is true for both standard images (by topic) and for user images!

On Tiki 15.x REV 59543 setting Articles out of the box;

There is a "un-natural" limitation for Article image size by default.
When I try to save an article with a picture heavier than 1mb (approx.) the article is saved without any error message and no picture is saved.

If I reduce size, the image is saved in the top image gallery without any acknowledgement, selection or choice. (openeing a discussion in the dev list)

It may be a system setting, but anyway, the user should be warned and the article should not be saved with improper picture ommited.

------

Out of the box I went to admin, activate the Articles feature.
I create a new article enter a title, heading, body and an image article.
http://bsfez-11581-6098.show.tikiwiki.org/tiki-read_article.php?articleId=1

The image is within several bootstrap classes (class="col-xs-6 col-sm-5 col-md-3") and it flows under the heading text making this feature broken.

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

The "box" command (carat) is NOT turned off by np nor pp tags, in ARTICLE.

The np and pp work correctly in the WIKI and BLOG.

I verified it with my
Wiki Syntax Test Page, replicated below.

[[UPDATE - it would appear that the horizontal line is also not working in this theme. And box tag does not generate a box, too.]
[[UPDATE 2 - I found that PREVIEW ARTICLE does not exhibit the error. Only after it is SAVED does the fault occur.]

Wiki Syntax Test Page

Bold Text
__Is this bold?__

Italic Text
''This should lean ''

Underlined Text
=== Look underneath me===

Strike Through
--Ouch, that hurts--

Headings, 1, 2, 3, 4
! #1 On Top
!! Looking Up, #2
!!! Hey, Watch Your Feet
!!!! Harrumph, fourth place

Horizontal rule (four dashes)
----
Line above me?

Box around text (carat)
^Let me out of here!^

Centered (in a box, too)
^::Stuck in the middle, again ::^

Square brackets
[["dig it"]

Title Bar
-=Champion of the Wiki=-

Shown / Hidden Headings
!!+ Peak a boo
Hide what follows
!!- Boo!
Show what's hidden beneath
and here ?
and here, too?
!! Clears the Hidden header section
And you can't see what follows "Boo!"

!!!!Testing the non-process flag (no box)
~np~^box free?^
~/np~

!!!!Preformated sections
~pp~
pp: Displays preformated text/code; no Wiki processing is done inside
these sections (as with np), %!)~*& == &~'p == (see?)
and the ^spacing is fixed (no word wrapping is done).^ If you see
a box, something is wrong!
~/pp~

~pre~
pre: Also displays preformatted text with fixed spacing, but
wiki __processing__ still --occurs-- on the text.
~/pre~

When viewing articles in list, the number of reads is not displayed anymore (option: art_list_reads) on new articles since Tiki 13. Tiki 12 has no problem.

The bug was introduced in revision 49060. New articles now have tiki_articles.nbreads NULL rather than 0.

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

I am using Articles for Events and need to sort them into order of occurrence using the Publish Date. That is not possible with the supplied files because the sort parameter has been hard coded.

I cannot let the own image of articles 'zoomable':
*text If I configure 'Article:Header text position' as 'Next image', the loupe zoom image disappears and I cannot zoom the own image any other way.
*text Even in the case of the loupe zoom visible, it does not respond when the article is associated with a topic. The entire image is hyperlinked. But it links to a list of articles of the same topic, not to the image enlarged. Maybe that can make sense when the image is a topic image. However, if the image is an own image for the article, one expects zoom it when clicks on it.

Consequences are for usability, as one expects to be able to zoom photos, and article's own images can be (for example, news contents). Furthermore, these images are usually shown in small size in order to save space (as these images are showed on the header section of the article), but its original size is bigger.

I would expect to always have the possibility to zoom the article's own image. Preferably as an hyperlink on the image itself.

{syntax type="tiki" editor="plain"}
As seen in the video attached to this item. (demo tiki)
The own image article is lost if the classification (topic or type) of an article is changed.

To reproduce;
In the Tiki Articles I create an article and set his own image.
I save, the image is displayed.

I edit the article change the topic or the type of the article and save.
The image is gone.
It was working fine, __this is a regression on Tiki 29__.

Currently, when you write __a new__ article at tiki.org and then click the preview button, the page refreshes with all the form empty, so all the inputs and edits are lost. (Seems like I reported this earlier, but the bug list search also didn't work when I tried to find it, so I'm not sure.)

The article feature has a setting, where you can define the sort order. It's a drop down list, but with just one option:

{CODE(Colors="Tiki")}
$article_sort_orders = [
'publishDate_desc' => tra('Newest first'),
];
{CODE}

Work in progress?

On tw.o, right now (at Friday 08 Jun, 2007 09:12 CET; 18:12 in Barcelona):

I got blank screen after submitting a new article submission on tw.o (user xavi, as plain registered user, using Firefox 2.0.0.4 under Window$), and some minutes later, from the same computer but using a different browser and user, I got blank screen after validating that article submission (user xavidp, SeaMonkey 1.1.2 under Window$)... However both actions succeded... (beyond the blank screen), even if they were posted more than once.

The article was submitted twice (as submission from user xavi), and, it's been posted three times when validated!

That's the article: http://tikiwiki.org/article150 (user xavidp cleaned the duplication in article submissions; sylvieg cleaned the 2 duplication in tw.o articles)

Can anybody confirm this is not any issue with my mouse or so?

Hi!

First: Thanks for this great project!

When you try to translate an article (by clicking on the small globe that is near the edit icon), it sends you to the wiki translation page, and content is empty, ie, it doesn't get the article's content to translate, and off course, even if it did so, the interface is not correct for article translation (it should have the same article interface, with heading and stuff).

I hasn't tried latest trunk, but bug is present on 5.1.

I tried to search for a similar bug already open (because of this forum thread: http://tikiwiki.org/tiki-view_forum_thread.php?forumId=13&comments_parentId=33126), but I found none, thus: I'm opening this open.

Thanks!

When editing an article the type is reset to the first in the list. This is due to an useless? foreach loop inside tiki-edit_article.php . See the patch attached for a solution.

Fast-breaking news, announcements. Submission & approval. Topics & Types.

After the creation of an article, it can be observed that the number of readings of this article does not change, even when changing users or the access permissions of a user. The number always remains at __(0 Reads)__.
I was using Chrome Version 75.0 and Opera Version:60.0

i have a problem with categorization.
when i add a new article. an old article in the tiki_categorized_objects got overwritten.
the objid and the href gets the new article id.
the result is that the old article losses its cat and the new article has the both.

when i take out the update in the method:
approve_submission
all is fine again:

catelib.php:

function approve_submission($subId, $articleId) {
$query = "update `tiki_categorized_objects` set `type`= ?, `objId`= ?, `href`=? where `objId` = ?";
//$this->query($query, array('article', (int)$articleId, "tiki-read_article.php?articleId=$articleId", (int)$subId));
}

what i find strange is the $subid at the end.

i'm not sure what the method is for. probably i broke something else.

i must add. i added a the category right in the database.
i added the articles by hand to the tiki_categorzed_objects
and added the category by using the topics from the article's.

When you create articles, e.g. with some news, you can format the text, the headline, and so on. You are presented some styling options, after all, like italic, bold, and so on.

But they don't work. Tiki displays the Wiki format commands as if they were regular text, it doesn't resolve (and execute) them!

Then there is a checkbox "allow full HTML". When you check that, you can at least throw in some bold and italic HTML tags. This works. In the preview... When you save that article, the checkbox magically resets to being unset. Even if done by admin...

Images are another shortcoming, you can upload your own. But you cannot use one from the file galleries?!? Yes, you can insert an image tag, and that does work. But it's the opposite of intuitional...

Thanks
hman

Tiki Articles do not support the FOOTNOTEAREA plugin. In Tiki 5 and 6 I used:
{CODE()}
foo bar {FOOTNOTE()}http://www.foo.bar{FOOTNOTE}
---
{FOOTNOTEAREA() /}
{CODE}

Tiki renders the footnote (superscript) properly, but does not include a Footnote area at the bottom of the article.

Tested & confirmed on info.tw.o using Tiki 5 and 6

When you choose "home Page" on left menu, and you have configured articles like your home, you are not redirected correctly.


I don't have a developer account to CVS. I'm working on 1.9 cvs.
rogeliotg

Quite strange, and maybe I missed somthing.

1-Create a new Article, and Topic,
2-Assign image to topic through Admin Topic
3-Select Topic..

All is ok, but it would be better to be able to scale the image, either at the Topic admin, or accept the Topic Own image scale factors.

Error part.
1-Select own image, Image uploaded.
2-Display ok.
3-Upload another Own image to replace the previous one.
4-Image name changes to the name of the new image, but the Image does not change.

The only way I can change the image is to select the Topic, but uploading a new image does not change the Own Image, what ever I do.

-I tried, Clearing all the Cache.
-Clearing and resetting local browser cache, This is not the problem, as I use Firefox and IE, and I edit with Fire fox, and then open IE to see if the image had changed, Plus I didn't run IE to see the previous image.

Work around is - I can delete the Article and create a new article of the same name, with the new image
But it would be nice if it worked as expected.

Apparent bug of undocumented feature within the ARTICLESplugin, such that the "start" parameter does not seem to function.

In the example below, This was coded into the body of a wiki page. I was trying to have two ARTICLES columns, but show the first 5 (or so) articles on the left of the wiki page, then continue with articles 6 thru (say) 10 on the right column of the split wiki page.

Gary (chibaguy) suggested the code below (including the "start" parameter), but it appears that I get identical lists of articles, rather than one column listing articles 1 thru 5, and another parallel one listing articles 6 thru 10 (as expected). "Start" doesn't appear to be documented, but Gary chibaguy suggested it's use to me.

{CODE(caption="example code to reproduce problem")}

{SPLIT()}
{ARTICLES(start=1,max=5)}{ARTICLES}
---
{ARTICLES(start=6,max=10)}{ARTICLES}
{SPLIT}

{CODE}

Please see http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=35859&thread_sort_mode=commentDate_asc#comments

Gary suggested that I submit this as a bug, so this is it. It would be awesome to be able to do a two column split of articles via the inline plug, but not when the lists are identical.

Thanks to you for looking into this!!! -sd :)

If you have an article listing on your front page, and you create a "breakout" page with older articles, you want to skip those that have already been presented on the front page. In order to achieve this, you can instruct the plugin to skip a number of articles (or a period). But this does not work together with pagination...

{CODE(Colors="Tiki")}
{articles max="6" topicId="2" largefirstimage="y" actions="n" title="News" quiet periodQuantity=3 start=5 periodUnit="week" more=y}
{CODE}

would be the code to display articles older than 5 weeks. And this works. But displays only 6 articles (as instructed). Once you add

{CODE(Colors="Tiki")}
usePagination="y"
{CODE}

The articles plugin no longer skips older news, but starts with the very same, newest article like to front page does... It does paginate, but it starts at the wrong article...

The following patch provides a version of the ARTICLES wiki plugin, that displays article titles only. To use, people simply specify titleonly=>1 in the options for the ARTICLES command. This is in production use on the [http://www.asperger.asn.au|Asperger Services Australia] website -- just look under ''News'' on the right-hand side of the page.

To filter articles by language:
{CODE()}
{ARTICLES(lang=>)}{ARTICLES}
{CODE}


Using the nifty lang & notlang as below gives more flexibility:
{CODE()}
{LANG([not]lang=>code[+code+...])}text{LANG
{CODE}

Articles do not have history. With wiki pages, there is always an undo (and multistage, and with comparison etc.). Articles don't have that, and I believe they should, and it shouldn't be hard to add... The revision system could be shared, or at least recycled, from the one wiki pages have.