Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 8 9 [10]
 91 
 on: February 13, 2013, 08:24:57 pm 
Started by mfaraklit - Last post by mfaraklit
Hi,

After i migrated my snews site's mysql database and hosting to new SSH enabled database and hosting, i have witnessed significant degree of visible slowness of my site loading. Is this related with new SSH database conflict or inconsistency regarding to Snews core codes.

Thanks.
   

 92 
 on: February 13, 2013, 05:00:05 pm 
Started by Fred K - Last post by Fred K
I figure it's easier/better I just show you what I mean, but I'm no way near far along in my refactoring to show anything yet. For a teaser of what I'm working on see http://code.google.com/p/cypress-cms/

 93 
 on: February 13, 2013, 04:55:50 pm 
Started by mattonik - Last post by Fred K
In hindsight, I think the SEF approach may have messed things up for future versions...

More the "lets-put-as-much-as-possible-in-the-articles-table" approach, imo.
Better separation (articles in articles table, pages in pages table and so forth) usually means more flexibility (though not always, for sure). I'm not hip enough to the SEF problem to have a real opinion though, but slaving through the pitfalls of the article forms has made me ... grumpy.

 94 
 on: February 13, 2013, 01:18:19 pm 
Started by mattonik - Last post by nukpana
- Categories: yeah, this I agree (mostly) on. I can see an angle for predominantly news-centric sites (think newspaper type sites) where categories as they are now are justified, but that can be seen as staying within the comfort zone. Mostly I agree with you. However - assuming one starts from an 1.7 (or 1.x if you will) base - that means a lot of rewrite to get rid of categories.
Lol or go back to 1.3 and use that as a base, since it was the last non-SEF release.  In hindsight, I think the SEF approach may have messed things up for future versions...

 95 
 on: February 13, 2013, 03:40:01 am 
Started by mattonik - Last post by Fred K
A couple of interesting points there, Jason.

- Community build: true, although the community (here) has a) dwindled substantially the past few years and b) not exactly been given a lot to work with. Historically, the community has always had a fairly big influence on what goes into the system. So "community build" doesn't necessarily have to mean opening up the whole build process to the whole of the community, in fact I would probably argue that keeping the building to a smaller group (but being very mindful of community input) is more efficient and effective.

- Categories: yeah, this I agree (mostly) on. I can see an angle for predominantly news-centric sites (think newspaper type sites) where categories as they are now are justified, but that can be seen as staying within the comfort zone. Mostly I agree with you. However - assuming one starts from an 1.7 (or 1.x if you will) base - that means a lot of rewrite to get rid of categories.

(Sidestep: trying to get rid of or rewrite intertwined functions, like extras for instance, is not a fun task. Might be better to build new functions instead. But as before it depends on the starting point.)

 96 
 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.....

 97 
 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.

 98 
 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?

 99 
 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..

 100 
 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.

Pages: 1 ... 8 9 [10]