Please login or register.

Login with username, password and session length
Advanced search  

News:

You need/want an older version of sNews ? Download an older/unsupported version here.

Pages: [1] 2 3 4

Author Topic: Future Features  (Read 10873 times)

Fred K

  • Still trying to learn stuff
  • ULTIMATE member
  • ******
  • Karma: 130
  • Posts: 2728
    • Personal
Future Features
« on: October 19, 2009, 01:23:11 AM »

It was suggested in the "New version..." topic that we should start a new topic for suggesting features we dearly would like to see in future versions of sNews. So I thought I'd start the ball rolling. Just keep in mind when suggesting features that a) they should be reasonable. A Punch button, although technically interesting, is probably not ... reasonable. And 2)  just because a feature is suggested it doesn't mean that it will be considered for inclusion soon, or indeed at all. That's not what this topic is for. This is the place where we say what we would like to see. What happens after that is an entirely separate process.

My first suggestion is a feature, two features actually, that I've found great use for when doing work in ExpressionEngine:

1. A summary, for articles. This is something in between a Description and the Shortened text that using [break] produces. It is basically an added textarea in the article form, where you can add a brief summary of your article. This summary can then be used in a couple of ways - for example we can imagine that it replaces the shortened text on the category index page (as well as in the menu_article_with_introtext mod, also known as lead_articles mod) if used, and it can be used by the RSS function (RSS Feeds have an item named summary already, that's not really used or at least not used fully, where this summary function has a natural landing place). I have for myself done a bit of experimenting with a summary function and even though i have yet to get it fully working, what does work fits naturally into the article creation 'flow', at least in my extremely humble opinion.

2. A "custom field" function. In short, this function would allow us to add input fields to (primarily) the article form. ExpressionEngine, like sNews, comes with a number of predefined form fields for user input. The custom field allows the user to determine the field type, to fit a specific use. The default set of input fields obviously covers what need for general use, but sometimes you find yourself needing to add special fields. This would be a "simple" way of doing so.

Ok, that's me, for now.
Who's next? ;)
Logged

Sven

  • ULTIMATE member
  • ******
  • Karma: 88
  • Posts: 2029
  • Chasing MY bugs!
    • hiseo.fr - rédacteur Web
Re: Future Features
« Reply #1 on: October 19, 2009, 09:27:02 AM »

Hello Fredryk
I totally agree on these 2 points and add for the summary the capability to have an image ID attached to the article.

Did someone talk abour going MU? (1 version for all).
Over.

Keyrocks

  • Doug
  • ULTIMATE member
  • ******
  • Karma: 449
  • Posts: 6019
  • Semantically Challenged
    • snews.ca
Re: Future Features
« Reply #2 on: October 19, 2009, 03:57:47 PM »

Did someone talk abour going MU? (1 version for all).
Over.

Not yet that I know of.
Logged
Do it now... later may not come.
-------------------------------------------------------------------------------------------------
sNews 1.6 MESU | sNews 1.6 MEMU

Patric Ahlqvist

  • Nobodys perfect, but Im pretty effing close
  • ULTIMATE member
  • ******
  • Karma: 65
  • Posts: 4867
  • “I'm a self-made man and worships my creator.”
    • p-ahlqvist.com
Re: Future Features
« Reply #3 on: October 20, 2009, 12:11:25 PM »

Not MU, no...
Logged
"It's only dead fish that goes with the flow... "
Updated

Sven

  • ULTIMATE member
  • ******
  • Karma: 88
  • Posts: 2029
  • Chasing MY bugs!
    • hiseo.fr - rédacteur Web
Re: Future Features
« Reply #4 on: October 20, 2009, 05:01:31 PM »

Joost

  • Guest
Re: Future Features
« Reply #5 on: October 20, 2009, 05:33:26 PM »

Not MU, no...
Why Pat?
 ???

They answered your question literally. No one talked about going MU. ;D
But you can..., if you want.... It's a first step. Hello, I'am Philippe (Welcome Philippe)....it is my first time here. and eh..., I  find it difficult to say....... I am a MU-hollic!! (applaus);)
Logged

centered

  • Guest
Re: Future Features
« Reply #6 on: October 30, 2009, 12:16:11 PM »

Features for 1.8 or 2.9 that I propose (or have been proposing) :

1. A new admin URL structure:
 I use in snLite and my newer experimental build this admin structure:  http://domain.com/admin/edit/id=1  What this does it I can check and remove against unwanted guests thoroughly like this functions:
Code: [Select]
// Remove null & emtpy variables from array
function array_remove( $var ) {
if ( !is_array( $var ) ) return;
foreach($var as $key => $value) {
if (!isset($value) || empty($value)) {
unset($var[$key]);
}
}
return $var;
}

// Checks URI against hard coded admin pages, removes all post uri if invalid
// Depends on adminPages()
// Returns array
function adminPageCheck( $uri ) {
$adminPages = adminPages();
switch (true) {
case ( isset( $uri[3] ) ) :
if ( !in_array( $uri[2], $adminPages['extend'] ) &&
$uri[2] == 'edit'
) {
$uri[2] = 'view';
}
break;
case ( isset( $uri[2] ) ) :
if ( !in_array( $uri[2], $adminPages['extend'] ) ) {
unset( $uri[2], $uri[3] );
}
break;
case ( isset( $uri[1] ) ) :
if ( !in_array( $uri[1], $adminPages['base'] ) ) {
unset( $uri[1], $uri[2], $uri[3] );
}
break;
}
return $uri;
}

function makeID( $array ) {
if ( !is_array( $array ) ) return;
if ( isset( $array[3] ) &&
strpos( $array[3], 'id=' ) === 0
) {
$array['id'] = escape( substr( $array[3], '3' ) );
}
unset( $array[3] );
return $array;
}

function uriArray() {
static $uri;
if (!$uri) {
if ( empty( $_GET ) ) return;
$uri = escape( $_GET['uri'] );
$uri = explode( '/', $uri );
$uri = array_remove( $uri );
if ( empty( $uri ) ) return;
if ( $uri[0] == 'admin' ) {
if ( __admin ) {
// Limit the admin to domain.com/admin/item/action/id
$uri = array_limit( 3, $uri );
$uri = adminPageCheck( $uri );
$uri = makeID( $uri );
} else {
// Login - domain.com/admin/login
$uri = array_limit( 1, $uri );
$uri = adminPageCheck( $uri );
}
} else {
// 3 level hierarchy
$uri = array_limit( 2, $uri );
}
}
return $uri;
}

admin is my base category.  All admin urls are based on that function so I can check against it
Array_Remove removes the ending key that the trailing slash creates
adminPageCheck checks and remover the uri keys that doesn't check against the predefined admin list (similar to cat_listSEF)
 - so if you enter domian.com/admin/blah/edit/id=1 - you go back to domain.com/admin/
 - if you enter domain.com/admin/page/edit/ - you go to domain.com/admin/page/view/ - no id is entered.
makeID -checks the last uri for id=Something and strips the id=. 
uriArray - limits, strips and checks against the uri structure - even limits the public viewing heirarchy to how ever many levels I want

Prepending snews_ to some admin links is not the correct way to go....

2. New database schema - new structure for content:
Code: [Select]
CREATE TABLE content (
meta_id INTEGER NOT NULL,
description VARCHAR,
keywords VARCHAR,
summary TEXT,
text TEXT
);

CREATE TABLE meta (
id INTEGER PRIMARY KEY,
parent INTEGER,
name VARCHAR,
uri VARCHAR,
date DATETIME,
location VARCHAR, -- used for extra, but can be used in place of for show_on_home
seq INTEGER NOT NULL DEFAULT 1, -- sequence
status INTEGER DEFAULT 1,
tag VARCHAR NOT NULL -- page, category, extra
);

I have noted this one a few times too.  Pretty much I merged and split the articles/categorues/extras/whatever tables into two. All content is in hierarchy of each other - no matter how you look at it. sNews has limited capabilities to allow further development like a category page, subpages, subarticles, fred's section. Here? You are not limited. You want your commentable, display_title, etc add a new table:

create table meta_options (
   meta_id interger - links to the meta table id
   display_title integer not null default 0
   commentable integer not null default 0
);

3.sNews 1.7 main query for public and private pages.  Good way to reduce the admin size and do somethign like this:
Code: [Select]
function resultSet() {
static $resultSet;
if ( !$resultSet ) {
$uri = array(); // start an array for the uri
$uri['uri'] = uriArray();  // get the uri from the processed function
if ( __admin && __adminURI ) { // if logged in and domain.com/admin/
if ( $uri['uri'][2] == 'process' ) {
$rs = $_POST;
} else {
$rs = adminResultSet( $uri['uri'] );
}
} else {
$rs = pageResultSet( $uri['uri'] );
}
if ( !$rs ) $rs['resultSet'] = '';  // define an empty result set
$resultSet = array_merge( $uri, $rs );
}
return $resultSet;
}
pageResultSet is like the current MainQuery/MainResult for 1.7 the same applies for adminResultSet
$rs = resultSet(); becomes my global array without using globals.

This reduces calling a result and setting a global, adding new items to the base query, then RE-introducing a global (as seen in the refactoring thread).  The whole 'global' information is passed as an array, as it was created. 

I can parse a 404 if I wanted to:
Code: [Select]
function loadTemplate( $template ) {
$rs = resultSet();  // here is my global
if ( isset( $rs['resultSet']) && !__adminURI ) { // if resultSet is not set, and the uri is not one of the admin links (adminPageCheck does that work for us)
unset( $rs );
$site = __link.'404';
header( "Location: $site" );
header( "HTTP/1.1 404 Not Found" );
selectTemplate( $template . '/404' ); // if you want a 404 template, do it
} else {
selectTemplate( $template . '/index' ); // here should be the main point where a user can define multiple templates within the selected theme if you will
}
}

4. Plugins:
Code: [Select]
// Plugin API
function addPlugin( $hook, $callback ) {
global $__plugin;
$__plugin[$hook][] = array('callback'=>$callback);
return true;
}

function execPlugin( $hook, $string = '' ) {
global $__plugin; 
if ( !isset($__plugin[$hook] ) ) return $string;
$arg = func_get_args();
foreach ( $__plugin[$hook] as $key=>$callback ) {
foreach ($callback as $call) {
$args = !empty($arg)
? array_merge( array( $string ), $arg )
: $string;
$string = call_user_func_array($call, $args);
}
}
return $string;
}
« Last Edit: November 01, 2009, 04:06:33 PM by equilni »
Logged

Patric Ahlqvist

  • Nobodys perfect, but Im pretty effing close
  • ULTIMATE member
  • ******
  • Karma: 65
  • Posts: 4867
  • “I'm a self-made man and worships my creator.”
    • p-ahlqvist.com
Re: Future Features
« Reply #7 on: October 30, 2009, 01:22:06 PM »

Not MU, no...
Why Pat?
 ???

Well, why no one talk about it I don't know, Philippe. I think, personally, that MU would be a 2'nd version, a "fork", a addon/MOD... Most site's is, to my knowledge, operated by one or possibly a few admins. In my case I've made sites that have been operated by a few most of the times, but they have settled with one login (small sites). And in my head we're aiming for a small, fast easy to use engine which in it self is contradictive when talking MU, no ?

I have little if any to add when it comes to code efficiency and making it optimized to perform the ultimate way. I have still opinions on a base level, hehe... If I may. And with all opinions on code issues by Joost, Jase, Fred, Key's and all (not forgotten none) I have only this to add - Whatever version is coming, is supposed to be as lightweight as possible, but still easy in DB call's, handling SEF's the proper way, as secure as it's humanly possible and code-wise optimized, yeah ? In this, my base level opinion, MU isn't adding anything to that.

I can see that there possibly is a wish for, need for craving for MU, but... The one there is (haven't tested that one, I must confess) isn't that working ? Developing a MU for next version is in my mind pretty low on the scale of priorities... But's that me, and I've been wrong before, hehe...

Finally, what next version is about is to make 1.6 and/or 1.7 best features and code into something that is better than those two in every which way we can think of... Think "starting over" and making it right - Thus making an MU is too much.
« Last Edit: October 30, 2009, 01:25:15 PM by Patric Ahlqvist »
Logged
"It's only dead fish that goes with the flow... "
Updated

Joost

  • Guest
Re: Future Features
« Reply #8 on: October 31, 2009, 04:33:47 PM »

And in my head we're aiming for a small, fast easy to use engine which in it self is contradictive when talking MU, no ?

It is not a contradiction:
- A lightweight system is a matter of architecture and proper programming. If however, we stick to the all-in-one-file doctrine, then it won't be doable.
- Making it easy to use, is al about designing a good user interface. For instance don't mix admin settings with editors settings. SMF does a pretty good job in separating member interface and administrator interface.
Logged

Keyrocks

  • Doug
  • ULTIMATE member
  • ******
  • Karma: 449
  • Posts: 6019
  • Semantically Challenged
    • snews.ca
Re: Future Features
« Reply #9 on: October 31, 2009, 08:30:21 PM »

And in my head we're aiming for a small, fast easy to use engine which in it self is contradictive when talking MU, no ?

It is not a contradiction:
- A lightweight system is a matter of architecture and proper programming. If however, we stick to the all-in-one-file doctrine, then it won't be doable.
- Making it easy to use, is al about designing a good user interface. For instance don't mix admin settings with editors settings. SMF does a pretty good job in separating member interface and administrator interface.

Bob's snewsMU.php file (snewsMU 1.6.3) is 154 KB in size (plus 2 more d-base tables for guests and users), compared to the normal (vanilla) 1.6 snews.php file at 115 KB. That's not so bad considering the flexibility provided in terms of managing permissions for four user-types (Admin, Super Editor, Editor and User).

When we're dealing with interface design, our current 'vanilla' template is spartan (very basic) but styling can be influenced considerably provided we use classes as much as possible for admin styling (Jason clued me into that some time ago). While they may be 'spartan' with the default distribution, site developers can spruce the Admin interface up by simply changing the style declarations in the stylesheet provided we use classes for the works... if we put them in from the start.

Again, going back to Bob's MU package, it does separate settings from editors' settings. By default, the Super Editor and Editor only have access to the Create/View/Edit content panel when logged in. The Admin determines what the Editors have access to when setting up their accounts (when Admin-only account creation is allowed) and that is limited only to:

1) Allow Comments Admin
2) Allow access to Files Management
3) Allow Site Owner privileges
   which lets them edit content by other authors; still no access to the site settings.

If I were to make an MU option available with future versions, I would not restrict it to coming only as a 'fork'; I would make it an optional sNews package... in other words have both the Single User and Multiple User packages available for all future versions... though I don't know how practical that would be. I am sure that we could continue to refine Bob's MU work to meet such an objective... if we chose to. :)
« Last Edit: October 31, 2009, 08:32:14 PM by Keyrocks »
Logged
Do it now... later may not come.
-------------------------------------------------------------------------------------------------
sNews 1.6 MESU | sNews 1.6 MEMU

Joost

  • Guest
Re: Future Features
« Reply #10 on: October 31, 2009, 08:56:39 PM »

Bob's snewsMU.php file is not lightweight at all. 
Logged

Keyrocks

  • Doug
  • ULTIMATE member
  • ******
  • Karma: 449
  • Posts: 6019
  • Semantically Challenged
    • snews.ca
Re: Future Features
« Reply #11 on: October 31, 2009, 11:50:45 PM »

Bob's snewsMU.php file is not lightweight at all.

Relative to what?
(added...) I don't know of any other CMS that light with multi-user capacity.
Logged
Do it now... later may not come.
-------------------------------------------------------------------------------------------------
sNews 1.6 MESU | sNews 1.6 MEMU

Joost

  • Guest
Re: Future Features
« Reply #12 on: November 01, 2009, 05:13:59 AM »

Bob's snewsMU.php file is not lightweight at all.

Relative to what?
(added...) I don't know of any other CMS that light with multi-user capacity.

Using your definition of lightweight (small file size === lightweight ??? ), you are probably be right.
So good luck with refining "Bob's MU work". ;)
Logged

Patric Ahlqvist

  • Nobodys perfect, but Im pretty effing close
  • ULTIMATE member
  • ******
  • Karma: 65
  • Posts: 4867
  • “I'm a self-made man and worships my creator.”
    • p-ahlqvist.com
Re: Future Features
« Reply #13 on: November 01, 2009, 11:44:42 AM »

Leightweight = small file size is, if not anyone else's, my definition... So, what is right definition ?

 
Quote from: Doug
If I were to make an MU option available with future versions, I would not restrict it to coming only as a 'fork'; I would make it an optional sNews package... in other words have both the Single User and Multiple User packages available for all future versions... though I don't know how practical that would be.

Which would bring a lot, do it not... I mean every addon/MOD made for each should be made for the other (give or take specific things) for instance...
Logged
"It's only dead fish that goes with the flow... "
Updated

centered

  • Guest
Re: Future Features
« Reply #14 on: November 01, 2009, 04:29:30 PM »

Lightweight would be in code, efficiency and expandability. 1.6 is none of that initially, so building upon that base and style, makes it less lightweight than just file size. Then after all is said and done, if the file size is small then you can declare it lightweight.

Ideally, you want to build the core engine for a single user and have MU as a plugin to the core not as a separate version. This is my thinking
Logged
Pages: [1] 2 3 4