[geeklog-devel] Next Geeklog Version - Feature Ideas
今駒哲子
komma at ivywe.co.jp
Mon May 26 20:20:03 EDT 2014
Tom,
> admins can create a demo site
It's nice. Thanks.
and, front-end framework UIkit is nice one.
I want many themes with this UIkit and HTML5 CSS3 responsive web design.
Ivy
--
2014-05-27 6:56 GMT+09:00 Tom <websitemaster at cogeco.net>:
> For the next version of Geeklog another feature request I think we need to
> prioritize is the lock down of certain features so admins can create a demo
> site.
>
> http://project.geeklog.net/tracking/view.php?id=1059
>
> Tom
>
>
> -----Original Message-----
> From: geeklog-devel-bounces at lists.geeklog.net
> [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom
> Sent: April-02-14 8:56 PM
> To: 'Geeklog Development'
> Subject: Re: [geeklog-devel] Next Geeklog Version - Feature Ideas
>
> 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
More information about the geeklog-devel
mailing list