Category: Blog

When sending an Article-Put, Tiki seems to process the email--indeed, if spits out a long array message. But on looking at the homepage, the item does not appear. List Articles shows the item, but with no body.

The Array message is attached (a series of attempts, separated by //Attempt

When a user fills the e-mail address field at tiki-send_blog_post.php?postId=XX with non-email-string, an e-mail per sentence is tried to send from the server.

A simple check for a well written e-mail adress in the field should prevent silly mistakes from novice users in tiki, but very annoying for the server mailing efficiency and sys admin annoyance redirecting mal-formed e-mail...

It happens in 1.8.5, and also in 1.9.0.

Although Tiki tracks reads for specific blog, it would be nice if Tiki tracked reads for a specific blog post.

I noticed today a bunch of trackback spam in my Tiki-powered blog.

According to Wikipedia, "Many blogs have stopped using trackbacks because dealing with spam became too burdensome."
http://en.wikipedia.org/wiki/Trackback

If you get trackback spam in Tiki, here is how to clean:

Using phpmyadmin, go to the table: tiki_blog_posts

And find the colums "trackbacks_to" and "trackbacks_from". They should contain:

a:0:{}

instead of the spam.


Now, a more permanent solution to avoiding Trackback spam would be nice. Checking how other blogging software does it should provide some tips.

Some ideas:
0- A way to turn it off (this exists in more recent version of Tiki 1.9.x, see "Trackbacks Pings" in the admin panel)
1- Easier mass deletion
2- Email notification to blog owner
3- Using an online service to check for spam.

{syntax type="tiki" editor="plain"}
When writing a blog post in master currently, trying to preview it causes a 500 error. Edge browser says "This page isn’t working right now - localhost can't currently handle this request."

When viewing a blog (tiki-view_blog), the post-level comments are not visible (there is no COMMENTS button). This forces users to first select the post's PERMALINK in order to see if there are any comments for a specific post.

The COMMENTS button should be visible for every blog post -- regardless if you are looking at tiki-view_blog or tiki-view_blog_post.

With the 1.10b (and latest svn changes) it is meant for admins to be able to change the creator of the forums.

Unfortunately, all users with permission to create blogs, can now create blogs for any other user - even if they can not post to them.

It seems that the latest file templates/tiki-edit_blog.tpl and .php requires that a value for the creator is passed back from the field Creator. Thus, the field has to be present with a valid content.

{syntax type="tiki" editor="plain"}
I just upgraded from 2.0 to 3.0 and discovered a problem with posting in blogs. The problem before was that users selecting "POST" from the main menu could post in anyone's blogs, even those who selected that no one could post in their blogs. Now the problem is they get an error message that says they do not have permission to post, even if it is their own blog. They can only post in their blogs if they do a "list blogs" and then use the pencil icon to post.

In summary:

1. Users can create a blog
2. Users can list the blogs and click the pencil icon to post in their blog.
3. Users cannot post in their blogs by clicking "POST" from the main menu.

I have enabled blogging and xmlrpc
and am attempting to use w.bloggar, raven or qumana to post to the blog.

w.bloggar is able to access prior posts only intermittently, though it does work usually on the second or third try. It can post, and use the more text feature if the more text is changed to ...page..., but modifying an existing post seems to delete the post or make it invisible.

raven can post but the title is missing. revising post also "deletes" it or makes it inaccessible via web. it seems ot be able to read prior posts.

qumana tells me that "this operation is ont supported by the blog" when trying to read prior posts. it posts, but title is missing.

Images that are added using the wiki editor (anyway the normal editor, I didn't check the wysiwyg editor yet) don't have a default class. This is the simple case of no containing box or anything added along with the image. Therefore it isn't possible for them to have a default style such as margin or border unless it is added manually by the page author. Or if it is specified by the stylesheet (.postbody img or .wikitext img, etc.) then ''all'' images in those divs get the treatment, including smileys and external link icons, etc.

I suggest adding a default class like "contentimage" to enable a default style. Page authors can always add a second class if needed.

When you try to create a ~np~ {CODE()} {CODE}~/np~ block in the
Wiki which contains $0 somewhere (which is, e.g., quite
common in Unix init scripts), the page won't be
displayed (white screen).

this is easily reproducable by inserting the following
into a Wiki page:
~np~{CODE()}$0 {CODE}~/np~

The bug was not present in previous versions (I
recently upgraded from 1.8.5 to 1.9.0).


And as you can see, it works correctly here in the Tracker:
{CODE()}$0 {CODE}

Currently there is no wikiplugin to place 1 or more blogposts on a wikipage (showing title and content of the blog).

The functionality should be similar to the wikiplugin_articles, so that the amount of posts and the blogId can be specified.

Using a wikiplugin instead of the module plugin or RSS gives the advantage that you can show entire blogposts and that you can include a permissions check, so that users that should not be able to see the post don't get it on the screen.

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).

[http://tikiwiki.org/tiki-view_blog_post.php?blogId=2&postId=249|See an exemple of result]


It was working fine in BRANCH-1-8

If I try to contact tikiwiki either with w.blogger 4.0 or 3.3 or with Ecto to post to a blog it don't work. It is as soon as when I setup the account the message ist that the XML returned from xmlrpc.php is invalid ...

So I think this is a major backdraft for those who are pro in creating content - I think there is a demand for using tools like those.

When creating or editing a blog, the __Display Options__ tab includes two fields:
* Blog heading
* Blog post heading

There is also a __Heading Preview__ button on the tab.

1. The __Heading Preview__ does not show any sort of preview -- it simply reloads the page.

2. When ''editing'' a blog, there is a second __Heading Preview__ button, also which does nothing.

Blog post comments are often overlooked by the blog owner, because the owner doesn't get notification of blog posts. I propose we add the option of getting notified when someone comments on your blog.

!!!What I do
I create a blog post with characters like less than, ampersand, etc.

!!!!#First problem
The individual blog post looks fine but the list of blog posts is all wrong: I see the encoding of these characters. ("&lt;" instead of "<")

!!!!#Second problem
When I edit my blog post afterwards, the textarea does not show the content I put in. It shows the html codes for less-tan, ampersand, etc. ("&lt;")
This is why I say the original contents are corrupted.

!!!Probable reason for bug
When a blog post post saved, it does not save the content properly, it saves "&lt;" instead of "<", etc.
Wiki pages do not have this issue and they save "<" when "<"< is entered.

With the Journal theme, blog descriptions (at the top of tiki-view_blog.php) are displayed with a #b7b7b7 (light gray) text color on a white background. Considering that text is small, this b7b7b7 to #ffffff contrast means that the text is not only hard to read, but even easy to miss, as can be seen in the attached screenshot.

This happens because the Journal theme specifies color #b7b7b7 for class help-block, and because blog descriptions have the help-block class. I understand that help text is made discreet. But frankly, such a low contrast is a readability issue. Moreover, descriptions are not help text. They do not warrant big red text, but with such a small size, I'm not sure they even warrant gray. I would have no problem if they were pure black.

I am not clear on what change(s) are best, but I don't exclude that ideally:
# help-block color would be changed
# Blog descriptions would be changed to use a different, more prominent class

Setting feature_tell_a_friend=n doesn't affect the "Email This Post" functionality for the blog, so visitors is always offered to mail the link for a post. Imho the admin should be able to choose if this is allowed or not.

Review this blog entry on tw.o:
Using view_blog_post:
http://tikiwiki.org/tiki-view_blog_post.php?blogId=26&postId=300

Using view_blog:
http://tikiwiki.org/tiki-view_blog.php?find=&blogId=26#postId300


Notice that with view_blog_post, this line __is__ displayed:
And change it to:
<form enctype="multipart/form-data" method="post" action="tiki-editpage.php" id='editpageform' name="editpageform">

But with view_blog, the code is __not__ displayed.

Blog entries should be displayed identically, regarless if you are view the blog or blog post.

You create a blog, Assing local perms to a group which name contains an space (or special characters such as é, è, ñ, ç, ...). Then when you attempt to delete the local permission, you don't succed. The url is something like:

http://domain/tiki-objectpermissions.php?referer=http%3A%2F%2Fdomain%2Ftiki-edit_blog.php%3FblogId%3D5&action=remove&objectName=BlogNAME

And it produces the error message saying somerthing lie "there is not enough information to show this page".

In Tiki 1.9.8.3, even if the feature is off, you can see references to trackback pings in tiki-view_blog.php , tiki-view_blog_post.php, tiki-edit_blog.php and tiki-blog_post.php

Proper feature checks for {$feature_blogposts_pings}, {$feature_trackbackpings} and if the feature is activated per blog should be done.