sNews Forum

General Category => Looking towards 2.0 => Topic started by: mattonik on January 11, 2013, 05:30:11 pm

Title: New version / Opening the code to other developers?
Post by: mattonik on January 11, 2013, 05:30:11 pm
Hi there,

browsed to snews site form nostalgy to see that there is nothing new.
How is this project? Is there something in works still or even the oop approach failed?

To not just complain, is there something, we users/programmers can do?

Are the core developers open to share the code yet or to accept someone else's code?

Is there any future for snews?
Title: Re: New version / Opening the code to other developers?
Post by: sibas on January 11, 2013, 06:09:49 pm
Hi mattonic
Is pretty sad but I donít think that exist any new project for sNews, except some talking and some codes around the forum.
sNews dudes have disappeared from here, only few keeps alive this forum..
Future for snews?
Just I don't know! Is pity because has so many possibilities.
Anyway ..If gather some people I will be happy to help in any way I can.
Title: Re: New version / Opening the code to other developers?
Post by: Keyrocks on January 11, 2013, 09:49:13 pm
1) How is this project? Is there something in works still or even the oop approach failed?
2) To not just complain, is there something, we users/programmers can do?
3) Are the core developers open to share the code yet or to accept someone else's code?
4) Is there any future for snews?

Hi Mattonik -  good questions. I'll try to answer them as short as I can.  8)
1) No progress. Nothing in the works.
2) No, there is nothing to work on.
3) There are no core developers and no code to share. Any offers of new code would be VERY welcome.
4) The future lies with the members. If enough members come together and make that future, it will exist.

1) I donít think that exist any new project for sNews, except some talking and some codes around the forum.
2) sNews dudes have disappeared from here, only few keeps alive this forum..
3) Future for snews?  Just I don't know! Is pity because has so many possibilities.
4) Anyway ..If gather some people I will be happy to help in any way I can.

1) Correct... just some discussion and sharing of un-verified code examples.
2) Correct. Most of the Dudes do log in once in a while to see what's happening. A couple of us log in a couple of times a day to check for legitimate registration applications (and delete hundreds that are not legit)... but that's it.
3) Yes, even as it is, sNews does have so many possibilities. It is what each user makes of it.
4) I'll be glad to join the "Help" team whenever it comes together too.  :)
Title: Re: New version / Opening the code to other developers?
Post by: mattonik on January 12, 2013, 12:27:53 am
Thanks for replies guys.

So I far as I understood, snews should move to new core, allow easy mod creating.
What else? Should it still stay one file cms?

If I would like to start a new project/team for snew 2.0, what should I do?
What are responsible people open to do?
Title: Re: New version / Opening the code to other developers?
Post by: Fred K on January 12, 2013, 02:05:28 am
Quote from: mattonik
If I would like to start a new project/team for snew 2.0, what should I do?
What are responsible people open to do?

Just my thoughts/opinions on this:

1. If you're serious about this, do it as a fork of sNews under its own banner. sNews is Luka's baby and to progress it without Luka involved at all (if that would be the case) then it is better to take the fork route. Keep the lineage [as far as possible] but be free to move in a new direction. In my opinion the appeal of sNews is and always have been its ease of use thanks to the "one file" dogma (it's been more than one file for some time now, but the idea still lingers...)

2. Assemble a core team with clear assignments. Strategise a roadmap for the project. Get a code repository such as github or similar with SVN for the project, for easy updating and tracking. Code, test, revise, test, revise, ...

3. Make sure the team pulls in the same direction and that each team member is clear on their assignments.

As for participation, I'm willing to lend as much of a hand as I can in between paying gigs. And I can offer the same that I offered to do when this was discussed last, among the "dudes", which is to user-test, document and -if necessary- help with communicating. I can also help out with UI design issues if needed. I do some php code but there are others much better at that than me, so...
You know where to find me if you need me. ;)
Title: Re: New version / Opening the code to other developers?
Post by: mattonik on January 12, 2013, 02:30:28 am
Thanks for your reply.
I will think about it.

I agree with the one file cms as be an easy to use solution and I even support it.
Title: Re: New version / Opening the code to other developers?
Post by: nukpana on January 28, 2013, 12:45:43 pm
I think Doug summed it up pretty well, and Fred echoed my statement of any new development needs to be as a fork.

Quote
Mattonik - Is there something in works still or even the oop approach failed?
I don't think a OOP approach was given a chance, not that a 100% OOP solution would be ideal for a project like this anyway. Bob Baker noted an OOP version of sNews should be a fork and Luka noted no OOP for 2.0 - I said use it if needed as any programming patterns.
Title: Re: New version / Opening the code to other developers?
Post by: BuLe Bali on January 28, 2013, 05:42:15 pm
Its nice to see there's some old fellas around here talking about the future.
Please do not forget the main POI that gets me attracted to sNews, it's lightweight build.
For thos trying to develop this one or the new core, please bear that in mind.. :)

Just my two cents though. :)
Title: Re: New version / Opening the code to other developers?
Post by: nukpana on January 29, 2013, 02:37:59 am
Quote from: mattonik
If I would like to start a new project/team for snew 2.0, what should I do?
What are responsible people open to do?

Just my thoughts/opinions on this:

1. If you're serious about this, do it as a fork of sNews under its own banner. sNews is Luka's baby and to progress it without Luka involved at all (if that would be the case) then it is better to take the fork route. Keep the lineage [as far as possible] but be free to move in a new direction. In my opinion the appeal of sNews is and always have been its ease of use thanks to the "one file" dogma (it's been more than one file for some time now, but the idea still lingers...)

2. Assemble a core team with clear assignments. Strategise a roadmap for the project. Get a code repository such as github or similar with SVN for the project, for easy updating and tracking. Code, test, revise, test, revise, ...

3. Make sure the team pulls in the same direction and that each team member is clear on their assignments.

I think before any of this is started, you should figure out why you are doing this - what problems are you trying to solve? I can think of a few off the top of my head, bringing the script up to date.

1. System extension/expandability.
2. Improved template system.
3. Improved Admin UI.
4. Better code & code separation.
Title: Re: New version / Opening the code to other developers?
Post by: mattonik on February 10, 2013, 10:10:33 pm
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?
Title: Re: New version / Opening the code to other developers?
Post by: Keyrocks on February 11, 2013, 08:29:05 pm
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.
Title: Re: New version / Opening the code to other developers?
Post by: nukpana on February 13, 2013, 01:34:55 am
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.....
Title: Re: New version / Opening the code to other developers?
Post by: Fred K on February 13, 2013, 03:40:01 am
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.)
Title: Re: New version / Opening the code to other developers?
Post by: nukpana on February 13, 2013, 01:18:19 pm
- 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...
Title: Re: New version / Opening the code to other developers?
Post by: Fred K on February 13, 2013, 04:55:50 pm
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.
Title: Re: New version / Opening the code to other developers?
Post by: philmoz on February 14, 2013, 09:04:24 pm

Better separation (articles in articles table, pages in pages table and so forth)

Articles are content, Pages are content. What differentiates them is how they are classified and output, so IMV should be in the same table. A different route to what you would be suggesting would be to simplify the articles table to have, simply, the content and then have a defining reference table that is used to access the content (articles) table.

content table
contentidtitlesefcontenttags

reference table
refIdcontentIdtypepublishedpublishedDateetc...
Title: Re: New version / Opening the code to other developers?
Post by: nukpana on February 14, 2013, 11:57:27 pm

Better separation (articles in articles table, pages in pages table and so forth)

Articles are content, Pages are content. What differentiates them is how they are classified and output, so IMV should be in the same table. A different route to what you would be suggesting would be to simplify the articles table to have, simply, the content and then have a defining reference table that is used to access the content (articles) table.
If we are talking about simplifying and adding modularity, there needs to be separation. This isn't solely about the db tables, it is also the code base as well. It is unmaintainable continuing as it stands.
Title: Re: New version / Opening the code to other developers?
Post by: nukpana on February 15, 2013, 12:08:23 am
More the "lets-put-as-much-as-possible-in-the-articles-table" approach, imo.
Right, and I can see where the initial thoughts were to have a small script that could do alot - fit similar pieces together (articles/pages/extras into one table) and simple theming (center() = public & admin routing, pagination, category article list, full page articles, pages, comment inclusion, etc etc).  The problem is when the site needs to grow, the system can't efficiently grow with it.
Title: Re: New version / Opening the code to other developers?
Post by: Fred K on February 15, 2013, 12:25:44 am
Articles are content, Pages are content. What differentiates them is how they are classified and output, so IMV should be in the same table. A different route to what you would be suggesting would be to simplify the articles table to have, simply, the content and then have a defining reference table that is used to access the content (articles) table.

Yes, true, and I'm not saying my suggestion is the best solution (I wouldn't know if it is - it may even be completely useless, for all I know), but I do feel that even though articles and pages both are content, they are content with different purposes. Look at the current articles() form, for example. The current output, even with the $_ID filter doesn't distinguish between content types, but oftentimes page output has different needs than article output and could/should therefore be treated differently. As in separately. Pages seldom need/want the infoline. Pages seldom need/want comments. etc. With better separation comes simpler handling. Obviously, even I can see it, the use of "type" in a reference table would allow more detailed control in an articles() function, but it would still be (I assume) a function that treats article and page content (more or less) the same. Instead we could have a simplified articles function just for articles and a simple pages function just for page output. Easier to maintain/develop/modify, easier to debug, etc. Not to mention simpler admin parts for each. At least, that's how I see it. But again, I might be falling off a cliff here... ;)
Title: Re: New version / Opening the code to other developers?
Post by: Fred K on February 15, 2013, 12:39:21 am
More the "lets-put-as-much-as-possible-in-the-articles-table" approach, imo.
Right, and I can see where the initial thoughts were to have a small script that could do alot - fit similar pieces together (articles/pages/extras into one table) and simple theming (center() = public & admin routing, pagination, category article list, full page articles, pages, comment inclusion, etc etc).  The problem is when the site needs to grow, the system can't efficiently grow with it.


Yup. And it's not just about site growth, it's also about changed demands in functionality. Every time I do an sNews site nowadays (both own and for others) the amount of modding because of functionality demands is growing exponentially. It's a long time since I put out an unaltered sNews site (apart from styling, that is). Even my own, modified baseline isn't enough anymore...
Title: Re: New version / Opening the code to other developers?
Post by: Keyrocks on February 15, 2013, 06:07:57 am
... even though articles and pages both are content, they are content with different purposes.

One of the conveniences I like with 1.7 is that we can edit an article and save it as a page with or without comments. It's also been relatively easy to modify the cats/subcats functions so that both article and page links are listed in cat/subcat menus. I don't know if separating articles and pages with separate functions and tables would make these two features more difficult to apply but I'd rather not lose them.  :)
Title: Re: New version / Opening the code to other developers?
Post by: nukpana on February 16, 2013, 12:28:03 am
Articles are content, Pages are content. What differentiates them is how they are classified and output, so IMV should be in the same table.
Comments, categories, file uploads, ads, etc, etc are all content too if you are putting it in that perspective.

The reason why Articles, Pages & Extras are grouped together is because they share common attributes, but then again not really.  A page, as sNews defines it, does not need a category, nor a extraid, etc, etc. An article doesn't need a default_page, page_extra. Extra doesn't need keywords, etc. etc. I hope you are seeing the picture, where grouping everything together does not make sense to do and should be discouraged.

One of the conveniences I like with 1.7 is that we can edit an article and save it as a page with or without comments.
Thats cool that it can be done, but how many times would one do something like this - for example needing to change from a static page to a dynamic, time-lined article or reversing it? About Me (page) to Design/About Me (Article in Category). It's one of those user scenarios that may be one offs that could be excluded out of core functionality and into a module/plugin. These are the types of things that need to be discussed and rationalized.

It's also been relatively easy to modify the cats/subcats functions so that both article and page links are listed in cat/subcat menus. I don't know if separating articles and pages with separate functions and tables would make these two features more difficult to apply but I'd rather not lose them.  :)
I don't think that would be an issue, but it that something that is decided in the template and not in the core system?  See where the confusion is - you like the simplicity of the theming:
Quote
I also still appreciate the simplicity involved with theming the site with one template (index.php) file and one CSS file.
but in your user case scenario, it doesn't work for a "core" system function. It really should be regarded as a module/plugin that can be further manipulated in the template view on output, so it can be specialized for you - because each sNews system as it stands is a unqiue system that is incompatible with each other and incapable of future updates - Fred sums it up earlier:

Every time I do an sNews site nowadays (both own and for others) the amount of modding because of functionality demands is growing exponentially. It's a long time since I put out an unaltered sNews site (apart from styling, that is). Even my own, modified baseline isn't enough anymore...

This is when the the problem needs to be looked at at a core level - what needs to be done to allow a unmodified core that users can upgrade and can be extended if needed. The benefit here is that if the core can stand and need little maintenance, then you won't need a big "team" - let the community work through plugins and share accordingly.
Title: Re: New version / Opening the code to other developers?
Post by: Fred K on February 16, 2013, 04:47:14 pm
This is when the the problem needs to be looked at at a core level - what needs to be done to allow a unmodified core that users can upgrade and can be extended if needed. The benefit here is that if the core can stand and need little maintenance, then you won't need a big "team" - let the community work through plugins and share accordingly.

Yup, well put. With sNews as it is today you basically have to modify the core file if/when you want to manipulate the output in some way. The core should ideally, as far as possible, be untouched (save for updates etc.)

Quote from: Keyrocks
It's also been relatively easy to modify the cats/subcats functions so that both article and page links are listed in cat/subcat menus. I don't know if separating articles and pages with separate functions and tables would make these two features more difficult to apply but I'd rather not lose them.

Personally I've never understood that use - a page assigned to a category is essentially, apart from the table position, an article after all. That doesn't mean it wouldn't still be possible to make a mod that does this, if needed.