Category: Article

On a Tiki23 in articles on the tiki "articles" view the URL of the article is changed for the URL in the article source field if there is one.

It is demonstrated at http://bsfez-11581-8053.show2.tikiwiki.org/tiki-view_articles.php
The first article (playing poker) href point to the correct URL
The second article (This is my title) href point to a wrong URL

It is using the Source URL that was set at : http://bsfez-11581-8053.show2.tikiwiki.org/tiki-edit_article.php?articleId=1#content_edit_article1-5

The following list of article show the correct URL : http://bsfez-11581-8053.show2.tikiwiki.org/tiki-list_articles.php

Many news sites and blogs use a large image above the article content (see stories at vox.com, dailybeast.com, mic.com, www.bucketlistly.blog, etc. for example), whereas Tiki is by default limited to a small image to the side of the content. It would be great to have an option in the editor to choose either big image above the content or smaller image to the side of the content. For articles this would be the topic image. For blog posts and other cases it would be the featured image.

Infinite scroll automatically loads more articles or posts as the user scrolls down the page, so it isn't necessary to click to retrieve the next article/post. This is a popular feature used at many news and other websites, and would be a nice enhancement for Tiki sites.

One possibility (maybe leading contender, though others could be evaluated) is https://infiniteajaxscroll.com. For open source projects this is available under the MIT license (so ok for Tiki). It's also listed at packagist.org (https://packagist.org/packages/webcreate/jquery-ias).

When you create an article and try to give formatting to it it puts weird symbols. For example, for bold, instead of putting a word bold it puts weird symbols around the word.

When you are trying to add a file to the article, so the reader can download it with a click, or when you want to add a link or if you want to add an image; all this buttons do not work.

Instead, at the moment that you are uploading the image or the file you will see some explanation of a code that you have to add to the body of your article so you can show an image or a link to a file in the Wiki.

This is not user friendly at all, __making the user experience very bad__.

Regards,

WYSIWYG articles are ok when displayed using tiki-read_article.php, plugin or newsletter but show html on tiki-view_articles.php

Check Article 2 wysiwyg
http://demo.tiki.org/11x/tiki-read_article.php?articleId=4

Now compare : http://demo.tiki.org/11x/tiki-view_articles.php
and also : http://demo.tiki.org/11x/tiki-index.php

This was discovered on a Tiki12 upgraded from Tiki9 using wysiwyg, but the issue is also there with no wysiwyg.
I suppose we should first focus on the non-wysiwyg issue and there are chances it will also be solved in wysiwyg. So no more about wysiwyg

!First, I remind how things should work, as all is fine in wiki pages
In HomePage, insert
~np~{HTML()}<iframe src="http://www.musarama.org/en/widget/slideshow/key/269c31354b3770e5e96e8eccb1fec97ced34f0fc0b" width="480" height="300" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>{HTML}~/np~

Approve → OK
This works fine as I understand it should, and as it worked in Tiki 9. Meaning there is a nice iframe with images in it.
See: [http://jyhem-9952-5156.show.tikiwiki.org/tiki-index.php]

!Second, I show the problem
Create new article and put inside
~np~{HTML()}<iframe src="http://www.musarama.org/en/widget/slideshow/key/269c31354b3770e5e96e8eccb1fec97ced34f0fc0b" width="480" height="300" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>{HTML}~/np~
→ It asks for validation but on viewing, the content of the HTML plugin is wiped!
I see it is wiped by editing the article, and I see the HTML plugin is empty.

I try again, checking ''Allow full HTML (Keep any HTML tag.)
If not enabled, Tiki will retain some HTML tags (a, p, pre, img, hr, b, i).'' but that seems to be ignored.
In re-editing, it does not even stay checked.
Anyway, that should not be the way to do this. HTML plugin should not require to check ''Allow full HTML''.

I attempt to insert my html code outside the HTML plugin but it still gets stripped out, even when checking ''Allow full HTML''.
See: [http://jyhem-9952-5156.show.tikiwiki.org/tiki-read_article.php?articleId=1]

So right now there is no way to insert stuff in articles like they could :-(

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