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 ... 8 9 [10]
 91 
 on: February 13, 2013, 01:34:55 am 
Started by mattonik - Last post by nukpana
Hi guys,

thanks all for their opinions.
Still thinking about doing this. New fork might be a good way but I would like to involve the existing community.

Maybe kind of CodeIgniter way might be a good way - provide the core sNews as it still is and then new community build one (CodeIgniter & CodeIgniter Reactor, even though they seem to unite it again). What do you think?

As for reasons I would like to go into this, I personally need some lightweight (even maybe file based) CMS with great user interface and easy configuration. And yes I know there already are many like this, but most of the open source simple CMS look terrible or are unusable in many ways.

I would like to build something in between Kirby, Statamic and Squarespace but open source and simple. How about that?
If you will be doing a fork, go all out. Or follow the 1.x series into the full fork - figuring out the 2.0, then working backwords, depreciating stuff in the process.  There are points in the sNews system, where you can bypass parts of the system. IMO there is so much to be changed/revised - working backwards may be a harder route, but the comminuty may appreciate it...for backwards compatibility leading to....

Community build - I think if community wanted this, then it would have been done already - but the fact is, none of the 1.x version are compatible with each other. Even considering doing a community build of 1.7 would be no where compatible with the base 1.7 - unless, as noted above, you "bypass parts of the system". This idea stems from my thread here: http://snewscms.com/forum/index.php/topic,8974.0.html

Kirby, Statamic and Squarespace - took a quick peek and thought the Squarespace admin was beautifully done! The template systems leave a bad taste since I am reminded of the Smarty template engine.  Do you have any specifics that you like about these systems other than what you mentioned?

I am considering helping out - as stated before I started a base framework to help whatever system wants it for now - http://snewscms.com/forum/index.php/topic,10292.msg69506.html#msg69506 Just note, I started a rewrite of it, but got preoccupied with other things, so I am going back as it was - left on the back burner....

Two of the features I like about sNews (as it is) s the use of global database queries at start of snews.php and having all (as much of as possible) the saving, updating and deleting of data processed by one function - function processing(). I also still appreciate the simplicity involved with theming the site with one template (index.php) file and one CSS file.
Doug, I think you picked two areas that could be removed if refactored or reworked properly:

 - Processing.  If an admin rework was to be done, this would be one of the top functions to refactored, then removed in future versions.  In talking about modularity, then about one function doing all the processing is contradictory - and yes, I do understand you are talking about what you like about 1.7 as it is. Currently the function is a prime example of breaking up into smaller functions, where processing could just be a hook, then depreciate it later on...

 - Global DB query.  It is there because there needed a way to determine the content type of the url - uri 1- page or category, uri 2 - subcategory or article or pagination, uri 3, etc etc. I noted if the uri were better structured and we promoted better urls (RESTful like), then this wouldn't be needed:

domain.com/?/admin - AdminController
domain.com/?/blog  - BlogController
domain.com/?/forum - ForumController
domain.com/?/store - StoreController
domain.com/?/about - PageController

Each uri-1 would be it's own uri controller, making the core system smaller and modular

domain.com/?/admin/article/edit/1
domain.com/?/blog/2013/2/13
domain.com/?/forum/latest-threads
domain.com/?/store/apparel/mens/shoes/
domain.com/?/about

@Mattonik -Side note - categories were given way too much priority... they are tags that should have been an search function like tag are today also see how Gmail uses labels (tags/categories). Please consider this.....

 92 
 on: February 11, 2013, 08:29:05 pm 
Started by mattonik - Last post by Keyrocks
I would like to build something in between Kirby, Statamic and Squarespace but open source and simple. How about that?

I have no experience with Kirby, Statamic and Squarespace though I see the last two are purchased solutions, not open source for self-customization or modding. Squarespace appears to be a nice, one-price full-service package and a good deal since it includes cloud-hosting... unlimited for $16/month... a great solution for anyone who just wants to get a site up and running with no modding or configuration to do.

But getting back to a 'next' version (or a fork) of sNews. I agree with the considerations Jason (nukpana) listed:
1. System extension/expandability.
2. Improved template system.
3. Improved Admin UI.
4. Better code & code separation.

Going with one file for the core functions is fine but when we go the modular route when building even a simple CMS, a modular structure means we will be building modules or plugins that can be easily added, enabled and disabled from the admin. And the modules or plugins will need to be easy to update when newer versions of them are available, all without requiring modification of the core files and database tables. So modules & plugins will have their own file-sets (for functionality) and d-base tables if required.

This approach means we'll have several folders with several files in them, with each module or plugin's file-set conforming to a specific structure and naming conventions so that they can be included by and operate seamlessly with the core engine functions.

Two of the features I like about sNews (as it is) s the use of global database queries at start of snews.php and having all (as much of as possible) the saving, updating and deleting of data processed by one function - function processing(). I also still appreciate the simplicity involved with theming the site with one template (index.php) file and one CSS file.

The more bells and whistles one wants in any CMS, the more back-end code (and files) will be required in order to make it all work.

 93 
 on: February 10, 2013, 10:10:33 pm 
Started by mattonik - Last post by mattonik
Hi guys,

thanks all for their opinions.
Still thinking about doing this. New fork might be a good way but I would like to involve the existing community.

Maybe kind of CodeIgniter way might be a good way - provide the core sNews as it still is and then new community build one (CodeIgniter & CodeIgniter Reactor, even though they seem to unite it again). What do you think?

As for reasons I would like to go into this, I personally need some lightweight (even maybe file based) CMS with great user interface and easy configuration. And yes I know there already are many like this, but most of the open source simple CMS look terrible or are unusable in many ways.

I would like to build something in between Kirby, Statamic and Squarespace but open source and simple. How about that?

 94 
 on: February 10, 2013, 06:42:48 pm 
Started by Fred K - Last post by nukpana
Not trying to argue, but....

Function archives? contact?

Did you look at the fix I posted?
http://snewscms.com/forum/index.php/topic,9272.0.html
 - other than the admin pages, which could be "hacked" into, I think this should work for you.

Did you miss the first screenshot I posted? in the previous post? Showing a contact me extra in the archive page?

The group could be a block of content or an area in the page. Name it what you want, it will still work the same.

Code: [Select]
<header id="masthead">
<?php echo extra('header-block'); ?>
</header>
<article>
<?php 
  
echo content(); 
  echo 
extra('post-content');
  echo 
comments();
?>

</article>
<aside>
<?php echo extra('aside-block'); ?>
</aside>
<footer>
<p>blah blah</p>
<?php echo extra('footer-block'); ?>
</footer>

I think we are describing the same thing.. a bit differently, but it is the same concept


re: Blizzard...
I am not bad, but people I know are still not plowed out. Thankfully everyone still has power..

 95 
 on: February 10, 2013, 06:31:40 pm 
Started by Fred K - Last post by Fred K
Yes I know extra contents have always been in the articles' table and originally multiple extras weren't available but with your contribution they now are, which is great.
What I am trying to accomplish though isn't something within the old but different from the old, in terms of how extra contents are handled.

1. Create extra content.
2. Where you want that extra to appear, call it with <?php extra('extra-content-seftitle'); ?>.
That's my scenario. Nothing else.

Now, yes, with the different layout of the extra table you propose (which is roughly the same as I had in mind) you could also create extra groups if you want (and that could be handled with a filter I suppose), but the main idea with "my scenario" is that extra content can be called in *anywhere*. Like functions archive(), or contact(), or menu_articles(), or new_comments(), to name a few. That's what I'm trying to do.
In essence, you *can* use extra groups if you like, but calling extra _content_ should not be limited by the extra content belonging to a group.

So it's not the same as the current extra function, given how it's used. It's the "same but different".
Also, I don't see current behaviour (or original behaviour for that matter) as a "bug", never have. I just want a different solution because I think it would improve certain aspects of it. If I can get it to behave as I want. ;)

so how's the blizzard going? Hope it's not too devastating.

 96 
 on: February 10, 2013, 05:13:37 pm 
Started by Fred K - Last post by nukpana
Right now, extras have always been part of the articles table.  The "extras" tables was trying to group the extras into logical blocks of content

Logically speaking, yes, each section should be modular to the whole.

Ideally, the tables should be:
Block                  - id, name (seftitle), content
Block Group        - id, name
BlockGroupAssoc - group_id,  block_id

Now in this scenario, one can do with or without the groups if so desired.

Quote
In my scenario, groups aren't needed at all.
Since I don't know your scenario, then in general I disagree -  I think the system is not configured properly to handle the extras anywhere, hence why I saw an immediate need to try and fix the issue - which no one claimed to be a bug.  There are endless amounts of possibilities if used correctly.

Now, I can use extras in the home/base pages (using my fix above), but it doesn't note the group name here, nor can I multi-select items within the extra content creation. And, for now, it can't be used with the admin pages....


Using 2 extra groups - one placed on the top and one normal one in the sidebar:


 97 
 on: February 10, 2013, 04:09:39 pm 
Started by Fred K - Last post by Fred K
Thanks! I looked at the 1.6 code and it seems promising.
What I'm having some problems understanding though is why it seems like although the db query is directed at articles, and what the function is looking for is 'seftitle', extra content is called in depending on *group seftitle*, which is set in the extra table and so shouldn't be part of the function at all.

What I mean is: query = SELECT blabla,seftitle,blabla FROM ._PRE.articles
result = group seftitle / extra content (regardless of seftitle).
= weird. (or maybe it's just me).

What I'd like is: query = SELECT blabla,seftitle,blabla FROM ._PRE.articles
result = extra content seftitle (LIMIT seftitle).

In my scenario, groups aren't needed at all.
Reworking my test in a more substantial way by removing the extra group parts from article contents form and processing. Thinking about putting extra content parts in "extras" db table, just to see what the fallout might be. Logistically speaking, extra content should be in extras table anyway, imo...

 98 
 on: February 10, 2013, 02:42:22 am 
Started by Fred K - Last post by nukpana
My initial idea on this was here for 1.6: http://snewscms.com/forum/index.php/topic,5977.0.html

I chose the group route, which came into 1.7, as you well know.

For 1.7, my "fix" to allow Extras on base pages including Home is here:
http://snewscms.com/forum/index.php/topic,9272.0.html

In the refactoring thread, I simplified it even more - but probably needed more to it... (above fix perhaps?):
http://snewscms.com/forum/index.php/topic,8391.msg61617/topicseen.html#msg61617

To me, the extra grouping would be ideal in this fashion:
Code: [Select]
<aside>
<?php foreach( extra('asideGroup') as $k => $block ) { ?>
<div class="extra">
<?php echo $block['content']; ?>
<?php echo $block['admin_link']; ?>
</div>
<?php ?>
</aisde>
You then regulate the content to the group, then what page (not the sNews type). Now it doesn't matter what the extra is, it is called within the group that it is associated with.

Let me know if I am understanding or misunderstanding you - but you should have some filtering reference in the above links

 99 
 on: February 09, 2013, 07:31:42 pm 
Started by Fred K - Last post by Fred K
So I had this idea that the extra content/extra grouping thing could be simplified to basically allow us to print a specific extra content, controlled by its seftitle, where ever. The result would be that you could do something like this in index.php:

Code: [Select]
<div class="extra">
<?php echo extra('seftitle1'); ?>
</div>

and for example on a page you could do a sidebar with a couple of other extras:

Code: [Select]
<aside>
<div class="extra">
[func]extra:|:seftitle2[/func]
</div>
<div class="extra">
[func]extra:|:seftitle3[/func]
</div>
<div class="extra">
[func]extra:|:seftitle4[/func]
</div>

The aim with this simplification is to remove the need for groupings and still be able to print just the specified extra content in the desired place.

I started out with a simplified version of function extra(), but it is obviously not enough as it in the current form will print all existing extra content in the same slot, so some kind of filtering is required and that's where I'm stuck.

Here's what I have now, which works but not as desired:

Code: [Select]
<?php
// CONTENT BLOCK (e.g Simple Extra)
function block($getBlock='') {
if(!_ADMIN$qwr ' AND visible=\'YES\''; else $qwr '';
$getBlock retrieve('seftitle');
$sql 'SELECT id,title,seftitle,text,position,displaytitle,visible 
FROM '
._PRE.'articles'.' WHERE published = 1 AND position = 2 ';
$query $sql.(!empty($getBlock) ? ' AND seftitle = '.$getBlock '');
$query $query.$qwr.' ORDER BY artorder ASC';
$result mysql_query($query) or die(mysql_error());
while ($r mysql_fetch_array($result)) {
if ($r['displaytitle'] == 'YES') {
echo '<h3>'$r['title'] .'</h3>';
}
file_include($r['text'], 9999000);
$visiblity $r['visible'] == 'YES' '<a href="'._SITE.'?action=process&amp;task=hide&amp;item=cy_articles&amp;id='.$r['id'].'&amp;back='.$url.'">'.l('hide').'</a>' l('hidden').' <a href="'._SITE.'?action=process&amp;task=show&amp;item=cy_articles&amp;id='.$r['id'].'&amp;back='.$url.'">'.l('show').'</a>';
echo _ADMIN '<p><a href="'._SITE.'?action=admin_article&amp;id='.$r['id'].'" title="'.l('edit').' '.$r['seftitle'].'">'.l('edit').'</a>'.' '.l('divider').' '.$visiblity.'</p>' '';
}
}
?>

Usage: where a block should appear, do <?php echo block('seftitle'); ?>, where 'seftitle' of course is replaced by an existing content block's seftitle.

The main reason I'd like to do this simplified version, apart from eliminating the need for groupings, is that extras (content blocks) would then be infinitely usable anywhere, including on home page or other system pages, and (in my view) easier to use and explain.

So, how or what do I do to be able to print specified extras (content blocks), given the current construction? Obviously changes will need to be made to articles form and processing, and the db would be altered, but that's a smaller problem.

Most grateful for tips, pointers etc.

// EDIT
I added a limiter, similar to archive(), and although it works it isn't quite the solution I want.

 100 
 on: February 09, 2013, 05:47:42 pm 
Started by Fred K - Last post by Fred K
Yup, now even I get it... :D
Works just fine, thanks. And yes, there are a few really nice (albeit cosmetic) uses for it.

Pages: 1 ... 8 9 [10]