[geeklog-devel] Next Geeklog Version - Feature Ideas

Wed Apr 2 20:56:01 EDT 2014

Some good ideas

1. Yes some sort of comments admin list and editor would be helpful. 

2. I agree. A lot of staticpages are not really static anymore. Maybe
default the name to "page" with the ability to have 301 redirects from the
old "staticpage" directory. I would still want the ability to keep the
directory name staticpage for my older sites (or other names if someone
desires). Would have to figure out the best way to do this though. The other
idea here would be to introduce into Geeklog Core some sort of php routing
framework like  Klein (https://github.com/chriso/klein.php). The staticpage
plugin could make use of it and we could eventually add topics, articles,
etc...

3. Not sure exactly what you mean here. Are you looking just to update the
modified files from a previous version?

4.  The configuration has a data filter. I wonder if we can update it to
make use of it somehow? It allows custom filters ( like number ranges,
email, paths, etc). 
I am sure there are open source filter classes for sanitizing and validating
maybe one of those would meet Geeklogs needs. There is even a PHP filter
extension.  We would have to look into this one further.

Tom
-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of cordiste
Sent: March-31-14 9:22 AM
To: Geeklog Development
Subject: Re: [geeklog-devel] Next Geeklog Version - Feature Ideas

Hi,

Here are my top feature requests:

1. An admin page for comments, with comments list, delete and edition links
will be helpfull.
2. Rename staticpages plugin to pages plugin or allow name customisation for
the folder public_html/staticpages 3. A tool to check files from a geeklog
install to get list of modified files, files that are not part of the
distribution...
4. A function to filter submitted variable like

/**
 * Filters submitted variables
 *
 * Uses geeklog functions to filter submitted variables for illegal content.
Any editing is
 * done in place and no value is returned
 *
 * @param array $vars associative array of variable name => type (type in
(number,alpha,text,html))
 * @param array &$arr reference to associative array of variable name =>
value  */ function paypal_filterVars($vars, &$arr) {
    // cycle through each variable applying the appropriate filter
    foreach ($vars as $var => $type) {
        switch ($type) {
            case 'number':
                $arr[$var] = COM_applyFilter($arr[$var], true);
                break;

            case 'html':
                $arr[$var] = COM_checkHTML($arr[$var], 'paypal.admin');
                break;

            case 'text':
                $arr[$var] =
htmlspecialchars(strip_tags(COM_stripslashes($arr[$var])));
                break;

            case 'alpha':
            default:
                $arr[$var] = COM_applyFilter($arr[$var], false);
                break;
        }
    }
}

Maybe we could also  publish a story on geeklog.net to ask ideas to the
community and publish a poll with the 10 or 20 big ideas.

Ben

2014-03-31 10:57 GMT+02:00 Wim Niemans <niemans at nlbox.com>:
>
> Needs that exist, not knowing if, or when yes, how they are implemented:
>
> - proper handling of ajax requests
> - a generic template (like there is for a glPlugin) for REST api's
>
> - generic exception class
> - proper exception handler
>
> - resource class for javaScript and stylesheets, integrated in a 
> extensionable page class
>
> - language class wrapper to access language array's in a multi language
environment.
>
> - better config class: add xPath capabilities
>
> - add invitations (to fight spammer registrations)
> - add a system Glossary (may pick up the glossary plugin)
>
> - support microFormats: vcf, ics, foaf, ....
>
> So far, so good. The following feature is highest on my list, but a huge
workload: introduce accounts.
> GL supports users, userGroups and accessRights. The feature has a linux
look and feel and allows for read/write access configuration per user,
group, 'members'  and anonymous. The state of the art is very, very good.
> The proposal is to add accounts (as a security and privacy measure). The
idea is that a user (a human, not a bot), is just a user and that there is a
different principal (the account) that is allowed to use the system. Though
it resemble userGroups, it is not the same.
> In order to use the system, there is a account created; this account has a
owner, and manages the access rights.
> New users must 'subscribe' to a account and the account owner can allow
users to 'subscribe'.
> Extrema are a installation with one account and a installation where every
user has a different account. Both display backward compatibility, but need
extra code in core.
> Having accounts allows for deleting a certain user without loosing
content. User are offered private content to share with their own, private,
community. Several admin features will go in account scope.
> Having accounts wil eliminate spamming since spam will be encapsulated
into a account.
> If ever GL moves into document management or stories will become
documents, account are a must-have.
>
> If there are more interested developers four this feature, I am willing to
set up a discussion to have the specs worked out. I've done this before
(with a LDAP at it's heart), but it was java.
>
> Wim
>
> On 30 Mar 2014, at 17:31, Tom <websitemaster at cogeco.net> wrote:
>
>>
>> What does everyone want to see in the next version of Geeklog?
>>
>> Ideas I have so far:
>>
>> - Create a page class (see pagination discussion)
>> - Cleanup of Core
>>       - Drop support of COM_SiteHeader, COM_SiteFooter (means a 
>> number of popular plugins will have to get updated)
>>       - Drop support for LDAP and Live Journal authentication
>>       - Drop support for MSSQL / PGSQL ??? (One, both or none)
>> - HTML 5 theme (if added drop old Professional theme)
>> - Integrate GSOC Calendar project (Ben??)
>> - Including the Menu Plugin with Geeklog distributions
>> - Plugin Repository GSOC project
>>
>> These are just some of my ideas to open up a discussion on what we 
>> want and can accomplish. Anyone have any other ideas or comments on mine?
>>
>> Based on the outcome of this discussion I will update our poor 
>> unutilized Roadmap page :-) 
>> http://wiki.geeklog.net/index.php/Proposed_Roadmap
>>
>> Tom
>>
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>>
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://eight.pairlist.net/mailman/listinfo/geeklog-devel