perl-evozon / pearlbee Goto Github PK

After successfully creating a new user, the password provided to the user does not successfully allow the user to login to the page. Digging into the database revealed that the salt field was missing which causes the user's login to fail. As far as I can see, it might me an issue with the resultset craete method for the User class.

Decouple the listing of dependencies in Makefile.PL and put it in a cpanfile instead, to further ease the use of cpanm --installdeps . as well as support installation using Carton/Pinto/Stratopan. This should be as easy to implement via the mymeta-cpanfile utility of Module::CPANfile:

perl Makefile.PL
mymeta-cpanfle --no-configure > cpanfile

You can further remove the dependency listing in Makefile.PL entirely and read the from cpanfile via Module::CPANfile->load("cpanfile")

Given you're using DBIx::Class anyway, why not use DBIx::Class::Candy to declare the result classes, then DBIx::Class::Migration / DBIx::Class::DeploymentHandler to generate the .sql files?

SQLite would make a great choice for small blogs and for experimenting with the software, and PostgreSQL is going to be a vastly preferred 'real' deployment option to MySQL for lots of people.

Plus ::Candy is so much prettier :D

Hi,

I followed the Readme but get an error (see below) when launching. Seems PearlBee::Helpers::Themes is missing, but I have no clue where that would be, since it isn't in the repo...

Watching lib/ bin/lib bin/app.pl for file updates.
Error while loading /Users/ec/DEVELOPMENT/PearlBee/bin/app.pl: Can't locate PearlBee/Helpers/Themes.pm in @inc (you may need to install the PearlBee::Helpers::Themes module) (@inc contains: /Users/ec/DEVELOPMENT/PearlBee/bin/../lib /Users/ec/perl5/perlbrew/perls/perl-5.18.2/lib/site_perl/5.18.2/darwin-2level /Users/ec/perl5/perlbrew/perls/perl-5.18.2/lib/site_perl/5.18.2 /Users/ec/perl5/perlbrew/perls/perl-5.18.2/lib/5.18.2/darwin-2level /Users/ec/perl5/perlbrew/perls/perl-5.18.2/lib/5.18.2 .) at /Users/ec/DEVELOPMENT/PearlBee/bin/../lib/PearlBee.pm line 35.
BEGIN failed--compilation aborted at /Users/ec/DEVELOPMENT/PearlBee/bin/../lib/PearlBee.pm line 35.
Compilation failed in require at /Users/ec/DEVELOPMENT/PearlBee/bin/app.pl line 6.
BEGIN failed--compilation aborted at /Users/ec/DEVELOPMENT/PearlBee/bin/app.pl line 6.

After some serious hassle of installing GD (for Auth::Captcha).

No luck with DB init:

www PearlBee # /etc/init.d/mysql start
 * Checking mysqld configuration for mysql ...     [ ok ]
 * Starting mysql ...                              [ ok ]

www PearlBee # mysql -u root -p < db_patches/create_tables.sql
Enter password: 
ERROR 1136 (21S01) at line 121: Column count doesn't match value count at row 1

ok, let's try the other magic line:

www PearlBee # mysql -u root -p < db_patches/set_up_new_db.sql
Enter password: 
ERROR 1046 (3D000) at line 22: No database selected

No PearlBee here running yet...

While porting PearlBee to PostgreSQL, I noticed that your password salt column (user.salt) is too small. It is defined as char(24), but when I was testing on Postgres, it was producing 25 character salts.

If you are using MySQL in Strict SQL mode, this insert will rightfully fail (as it does in Postgres). If you want to run PearlBee and have a better-than-default config, your blog will break.

Every time, the first Captcha attempt (when submitting a new comment) is "incorrect".
The 2nd time works, if you type it in correctly.

When I submit the form in /admin/users/add I get a warning "Something went wrong. Please contact the administrator.". The output on the server is:

192.168.1.67 - - [08/Feb/2014:23:17:38 +0100] "GET /admin/users/add HTTP/1.1" 200 11147 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Firefox/26.0"
Odd number of elements in anonymous hash at /root/perl5/perlbrew/perls/perl-5.19.8/lib/site_perl/5.19.8/x86_64-linux/Template/Base.pm line 57.
Use of uninitialized value within @_ in anonymous hash ({}) at /root/perl5/perlbrew/perls/perl-5.19.8/lib/site_perl/5.19.8/x86_64-linux/Template/Base.pm line 57.

The relevant piece of code in User.pm:

      Email::Template->send( config->{email_templates} . 'welcome.tt',
        {
            From    => '[email protected]',
            To      => $email,
            Subject => 'Welcome to PearlBee!',

            tt_vars => { 
                role        => $role,
                username    => $username,
                password    => $password,
                first_name  => $first_name,
                url         => config->{app_url}
            },
        }) or error "Could not send the email";
    };

I would love to be able to host multiple blogs using PerlBee, a little like you can with wordpress or drupal. I am afraid that I can't contribute any time to adding this, but thought it's be worth adding a feature request.

An admin should not be able to disable/suspend themselves. Technically they can also then activate themselves again (which I'm not sure is better or worse), but the easiest way to solve this would just to not let them disable themselves in any way.

On a fresh Debian 7 x64 droplet at digitalocean.com I ran ...

apt-get install build-essential
apt-get install libgd2-xpm-dev
./build.sh

and a lot of dependencies installed but after some time I got a failure message ...

Successfully installed Sub-Exporter-ForMethods-0.100051
! Installing the dependencies failed: Module 'CPAN::Uploader' is not installed
! Bailing out the installation for Dist-Zilla-5.015.
167 distributions installed
./build.sh: line 5: dzil: command not found
user@somehost:~/PearlBee# ./build.sh

It seems Net::SSLeay was the issue and doing the following fixed it:

apt-get update
apt-get install libssl-dev
./build.sh

I then ran into this issue:

Configuring XML-SAX-Expat-0.51 ... OK
==> Found dependencies: XML::Parser
--> Working on XML::Parser
Fetching http://www.cpan.org/authors/id/T/TO/TODDR/XML-Parser-2.41.tar.gz ... OK
Configuring XML-Parser-2.41 ... OK
Building and testing XML-Parser-2.41 ... FAIL
! Installing XML::Parser failed. See /root/.cpanm/work/1398011586.16659/build.log for details. Retry with --force to force install it.
! Installing the dependencies failed: Module 'XML::Parser' is not installed
! Bailing out the installation for XML-SAX-Expat-0.51.
! Installing the dependencies failed: Module 'XML::SAX::Expat' is not installed
! Bailing out the installation for XML-Simple-2.20.
85 distributions installed

It seems I was missing another library and doing the following fixed it:

apt-get install libxml2-dev
./build.sh

If I have time I'll create a patch to the README and/or build.sh to help.

If you're using eval to capture errors, you have to at least report it. When posting a new post, the eval just swallows the error without reporting.

The current namespace is "perlblog" and "Model". These are both unsuitable.

Additionally, the repo should then be renamed to reflect the new namespace.

There is no way for an administrator to reset a user password.

Right now creation of users (which should be reserved to Administrators only) can be done by authors. An author can create another author and even another administrator.

I'm not sure what the rationale is for storing the application URL in the session cookie but if you change some things in the server setup it can cause problems. I just switched from a plackup development server on port 5000 to Apache and kept getting a CSS- and JS-less site that hung waiting for these resources to be loaded from the old URL. Clearing the cookie fixed this.

There are four different ways to reference these resources being used in the templates:

views/emails/new_comment.tt
10:     <link href="[% url %]/blog/css/bootstrap.min.css" rel="stylesheet">
views/emails/new_user.tt
10:     <link href="[% app_url %]/blog/css/bootstrap.min.css" rel="stylesheet">
views/layouts/admin.tt
19:      <link href="[% session.app_url %]/admin/css/bootstrap.min.css" rel="stylesheet">
views/components/datatables.tt
2:<script src="/css/DT_bootstrap.js"></script>

At least the last one will probably break on installations that don't live in the server root. Changing session.app_url to app_url in views/theme/styles.tt doesn't seem to cause any ill effects (haven't tested much though).

Can't build latest PearlBee on Arch GNU/Linux:

$ sudo ./build.sh 
Invalid version format (version required) at /usr/share/perl5/vendor_perl/Module/Runtime.pm line 349.
Compilation failed in require at /usr/share/perl5/site_perl/Moose/Autobox.pm line 15.
BEGIN failed--compilation aborted at /usr/share/perl5/site_perl/Moose/Autobox.pm line 15.
Compilation failed in require at /usr/share/perl5/site_perl/Dist/Zilla/App/Command.pm line 9.
BEGIN failed--compilation aborted at /usr/share/perl5/site_perl/Dist/Zilla/App/Command.pm line 9.
Compilation failed in require at /usr/share/perl5/site_perl/Dist/Zilla/App.pm line 8.
BEGIN failed--compilation aborted at /usr/share/perl5/site_perl/Dist/Zilla/App.pm line 8.
Compilation failed in require at /usr/bin/site_perl/dzil line 9.
BEGIN failed--compilation aborted at /usr/bin/site_perl/dzil line 9.

PearlBee still uses the old dispatching style. This has been superseded by to_app keyword.

Currently moving away from this can be done easily by using appname everywhere. It seems like this is just what's needed. I'll work on a PR for this.

In many places in the application, we see session('app_url') (in the code) or [% session.app_url %] (in the templates). I don't understand what this provides, since all absolute links (starting with /) would resolve to links in the application.

The only thing really needed would be the mount point, if the Plack application was mounted under some path below the absolute root (/), so that absolute links would include it.

I have a PearlBee installation that I've been using more or less as a personal diary for over 2 years. I would like to do more with PearlBee. I often meet people that are interested in using a system such as PearlBee.
With the current code, I can not seem to get a new working PearlBee up and running. My old one runs fine, just with not all the features working. Changes to the code have been made since my first installation 2 years ago. I get the feeling that most of those working on this software have moved on to maybe Perl 6 stuff.
Is there another Perl blogging software that can be recommended? Will development continue on PearlBee? I could try to help, but my coding abilities are still not up to a level that most coders would find useful. Is anyone willing to patiently bring me along to a point where I can contribute to this project? Or will the code base come to a point where it works? Or should I move on to another project? I like Perl, I wouldn't mind learning Perl 6. I'm looking for suggestions, but really need a blogging platform that I can start using for other peoples projects.

PearlBee install suffers from GD problem:

t/GD.t ........ 7/11 
#   Failed test 'image comparison test 7'
#   at t/GD.t line 249.
# Looks like you failed 1 test of 11.

This reported as a bug with GD (https://rt.cpan.org/Public/Bug/Display.html?id=106594), but I don't want to hold my breath until this might be fix.

Please think about a better alternative.

It appears the test scripts need to be updated. Also other files reference perlblog:
.gitignore
dist.ini
MANIFEST
MANIFEST.SKIP

A DBIx::Class warning:

DBIx::Class::Componentised::inject_base(): Use of DBIx::Class::UTF8Columns is strongly discouraged. See documentation of DBIx::Class::UTF8Columns for more info

It would be nice to see some screenshots on pearlbee.org so I don't have to download and install the application to have a look at the admin interface. No matter how easy this might be considered (matter of viewpoint), a screenshot is always simpler.

SQL::Translator has a problem:

SQL::Translator::Parser::DBIx::Class::parse(): Ignoring relationship 'settings' on 'Timezone' - related resultsource 'Setting' does not contain one of the specified columns: 'foreign.timezone_id'

When logging in, we generate session data for the user. If an administrator changes anything in the user data while the user is logged in, this doesn't get recalculated. The user will have to log out and log in again in order to see what changed.

Instead, only the user ID should be stored, and the user data should be fetched at a before hook. This allows the data to be fresh whenever a route needs to check it or render a template that needs to check it.

Another solution is have every call that changes that data to refresh it, but that's much more work with no gain really.

I tried doing this but had some problems which means I might need to solve #44 first.

Currently Makefile.PL still contains the scaffold defaults.

I am not quite sure, but I found that nearly all .pm files which contain statement like
template '/admin/posts/list' must be changed to template 'admin/posts/list'
or, a Runtime Error like this will be throw:
Failed to render template: file error - /admin/tags/list.tt: not found at /usr/local/share/perl/5.20.2/Dancer2/Core/Role/Template.pm line 132.
Basic environment of my machine:
ubuntu 15.10
perl 5.20.2
Daner2 0.166001

When using SQLite as a backend, the created_date for the post can't be NULL. In MySQL, it uses the default CURRENT_TIMESTAMP.

DBI Exception: DBD::SQLite::st execute failed: NOT NULL constraint failed: post.created_date [for Statement "INSERT INTO post ( content, cover, created_date, slug, status, title, user_id) VALUES ( ?, ?, ?, ?, ?, ?, ? )"] at /Users/anwalker/Projects/PearlBee/local/lib/perl5/DBIx/Class/Schema.pm line 1077.

The blog_path setting is not used anywhere in the templates or the code, so it can probably be safely removed.

Setting up the database as per the README leads to the following error when plackup's web server receives a request:

[PearlBee:20246] error @2015-05-04 00:40:12> Exception caught in 'core.app.before_request' filter: Hook error: DBIx::Class::ResultSet::first(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'me.multiuser' in 'field list' [for Statement "SELECT me.timezone, me.social_media, me.blog_path, me.theme_folder, me.blog_name, me.multiuser, me.id FROM settings me"] at /var/www/blog.towiski.de/PearlBee/bin/../lib/PearlBee.pm line 46

Running mysql -u root -DPearlBee < db_patches/set_up_new_db.sql fixes it. The (manually maintained, I suppose) create_tables.sql script seems to be out of date and missing at least these two lines:
multiuser TINYINT(1) NOT NULL DEFAULT '0',
id INTEGER NOT NULL PRIMARY KEY