Save a link fails - Untitled

[kth1]

Hi,

Wallabag seems to be a great piece of software, but at the moment I have a problem saving new links.
I installed v1.7.0, imported successfully my pages from Pocket. But if I try to save a new link (using Save a link or FF plugin), I get an empty entry in the DB with the content Untitled - estimated reading time : < 1 min.
Using an own root server with Plesk, CentOS 5.9, PHP 5.4.28, compatibility tests show OK (all green except of Tidy).

What´s wrong, what can I do, is there any FAQ entry for this topic ?
Thank you for a short reply
Karsten

[nicosomb]

Hi,

Can you enable tidy please ?

[kth1]

Hi Nicolas,
thank you for the quick reply!
I enabled Tidy, all lines in compatibility test are green now.
The problem still remains ... a new entry "Untitled" shows up.

[mariroz]

@kth1, could you pls try dev version of wallabag: now it contains some fixes which may help you.

[kth1]

installed current dev version, problem remains. New entries are empty and untitled.

[tcitworld]

It probably will have nothing to do with your issue, but I will share my story :
Tried to wallabag a link ten minutes ago, and the problem was just the same : Untitled, unable to get content, etc. This was rather strange, given that articles from the same site had worked earlier and I could test multiple versions of wallabag without success.
I finally thought to make a ping google.com from my VPS, which returned ping: unknown host google.com.
Turns out that the DNS servers I was using (Comodo DNS) were (are still ?) down and the request couldn't work. I just changed my DNS to others and restarted the network service and my article came right away.

It's just stupid, when you think of it, but I'll put something in a FAQ to check connection before starting to submit a bug to wallabag.

[kth1]

@tcitworld: thanks for the hint, but it´s not the solution. I downloaded wallabag by wget successfully, and ping run fine. Also checked the firewall rules - no outgoing restrictions.

[tcitworld]

Could you provide us a link you want to wallabag to be sure it runs on our side ?

[kth1]

well - I tried with some URLs:
http://google.de
http://www.laub-home.de/wiki/DansGuardian_Filtering_Proxy_unter_Debian_/_Ubuntu_Linux
http://wiki.ubuntuusers.de/Inhaltsfilter
The wallabag demo site saved it fine.

[tcitworld]

Yup, works well also on my side.
A couple of questions, if you don't mind :

• could you provide us a phpinfo() ?
• what storage system do you use (SQLite/MySQL/Postgre) ?
• could you see anything relevant in your php or webserver logs ?
• could you show us permissions into the wallabag folder ?

[kth1]

phpinfo: http://wallabag.xxx.org/phpinfo44232.php

using MySQL-DB, seems to run fine, as I can see the 210 other imported entries, and a new entry is appended (but as an empty untitled one)

Error logs: there are some errors like
[Sun Jun 01 12:33:31 2014] [error] [client 212.255.125.xxx] PHP Notice: Use of undefined constant ATOM - assumed 'ATOM' in /var/www/vhosts/xxx.or
g/wallabag/inc/3rdparty/libraries/feedwriter/FeedWriter.php on line 207
[Sun Jun 01 21:21:45 2014] [error] [client 212.255.125.xxx] PHP Notice: tidy_parse_string(): Unknown Tidy Configuration Option 'merge-spans' in /
var/www/vhosts/xxx.org/wallabag/inc/3rdparty/libraries/content-extractor/ContentExtractor.php on line 177, referer: https://wallabag.xxx.org/
I think the first one is solved with the current dev version, but the second one remains. Where should I configure Tidy ?

I thought about the file permissions, too. Parallels Plesk Panel is installed. xxx-org:psacln is the owner, most files have 644 and folders have 755, some 777.

[kth1]

now I checked ContentExtractor.php - merge-spans is set to true. Didn´t touch the file, it´s originally the one from the wallabag zip file.
Maybe you could provide me an info which file permissions I should apply on files and folders ?

[tcitworld]

Yeah, I think your tidy version is too old : the merge-spans option has been added on 13 August 2007 and your phpinfo says 11 February 2007 for tidy.

[tcitworld]

This shouldn't be the main issue, considering you didn't manage to save your articles without tidy. But it might help.

By the way, sudo yum install libtidy libtidy-devel might set your tidy library up-to-date.

[kth1]

okay, think I have to learn how to upgrade it ... it´s a root server, but with Plesk installed, i.e. I have to check how to install a newer version without influencing PHP and other components Plesk could use. :-) Maybe I have to add another repository. yum install libtidy libtidy-devel:
Package libtidy-0.99.0-12.20070228.el5.centos.x86_64 already installed and latest version
Package libtidy-devel-0.99.0-12.20070228.el5.centos.x86_64 already installed and latest version
Nothing to do

When installing tidy I had to use yum install php-tidy.x86_64, since an error occured on php-tidy:
Error: Missing Dependency: libtidy-0.99.so.0 is needed by package php-tidy-5.4.28-34.el5.art.i386 (atomic)
libtidy is installed, a yum clean all didn´t change anything.

But ... you are right, it shouldn´t be the main issue. I remember trying wallabag some weeks ago (mid of April), and it ran fine. Since this time I run some yum update and some Plesk updates, which may have influenced the php environment.
Maybe the file permissions ?

[tcitworld]

About the file permissions, I personally run a chmod 755 -R wallabag/ to make sure all file have the right access rights. (or even chmod 775). Not much secure, but if it turns to be the issue, you can always change afterwards.

Otherwise, disable tidy and check the php/webserver logs again. On my side, the links you're given work even though tidy is disabled.

[kth1]

Thank you ! It works !! :-)
I had to chmod 777, but I think that´s no option esp for config.inc.php. I´ll try to get a configuration with correct owners and chmod rights. rsync from wallabag zip file overwrites the owner to root, so I have to set it again.

[tcitworld]

Good for you. :)
File permissions are often hard to deal with, I really had trouble at the beginning on my own server.

I'll have to add this in a FAQ some time, to double check the file permissions.

[kth1]

Ok, it works. tidy disabled.

chown -R xxx-org:psacln wallabag/
chmod -R 775 wallabag/
find wallabag/ -type f -exec chmod 644 {} +
chmod -R 777 wallabag/cache/
chmod -R 777 wallabag/db/

Thank you for your patience and the helpful hints !
Maybe you could add a hint for the permissions needed after upgrading with rsync ;-)
And sometimes I´ll find out how to add the correct repository for upgrading tidy.

[tcitworld]

No worries. :)
I've just think of it, when you will have a second, could you just reactivate tidy too see if it works anyway with the version you've got ?

[kth1]

I re-enabled tidy and ... the error occurs again: empty with "Untitled" entry ...
Disabled Tidy - and it works fine.
The error was the same as before:
[Mon Jun 02 09:23:38 2014] [error] [client 212.21.xxx.xxx] PHP Notice: tidy_parse_string(): Unknown Tidy Configuration Option 'merge-spans' in /va r/www/vhosts/xxx.org/wallabag/inc/3rdparty/libraries/content-extractor/ContentExtractor.php on line 177, referer: https://wallabag.xxx.org/

There was an additional error - I had to chmod 777 assets/ because of an error occuring in line 140 of pochePictures.php.

[tcitworld]

OK, thanks for the test.

[mariroz]

Hi to all,
I noticed, that due to various versions of software, used by our customers, errors like "PHP Notice:..." are often common...
Notices are not critical and wallabag can proceed and produce valid output in 99% of such cases, but "Notice ..." output often break all the flow as we get invalid json or rss.
Important is to note, that error reporting level in productions environment usually should NOT output any notices, so our customers often use dev or custom php.ini settings.
According to it, I propose to add appropriate constant - say, WALLABAG_ERROR_REPORTING - in wallabag config and set it in 32759 (E_ALL & ~E_NOTICE) by default. Then, in index we can silently (to prevent another notices, for example in safe mode) set error reporting level. In out dev environment we should always use E_ALL, of course.
This will safe us a lot of time for support of v1. In v.2 we can start with E_ALL to find all potential problems, I think.
If you agree - will implement.

[tcitworld]

Well, in that case the Notice was blocking the execution of wallabag, but I see your point.
However, instead of relying on another constant, I think we could rely on the existing DEBUG_POCHE constant, don't you think ?

[mariroz]

n.p.: we can use DEBUG_POCHE - doesn't matter. Important is, that I propose to change error_reporting level. Do you agree?
But as for me, i don't see a problem in another constant: it will not affect customer's config file as default config is now separated, but will give us more flexibility, I think.

[tcitworld]

Yeah, maybe. Do as you want. :)