Righty. Let's get real about making this thing usable. How about a portal?
Doesn't have to have every bell and whistle under the sun, and would arguably be better if it didn't.
Necessary in at least basic form though, in my opinion, because a bog basic forum just doesn't cut it any more.
Separate front page (doesn't need standalone or any fancy biz).
Only needs front page content laid out straight down the page: much more tolerant of different screen sizes, less bloat.
Basic panels: left, right, top, bottom.
Basic block types: php, html, bbc, js, user stuff, shoutbox, recent posts, couple of others, whatever.
Proper articles system, with categories and menus for such.
Bugger all else.
IOW, sorta like TP before it went crazy, but with clean code, or like SP but with a real articles system.
Thoughts?
We had a few short discussions touching this. (there should be something in IRC logs since IRC channel started). In fact, with you too a while ago. :)
I haven't tested TP, I assume it won't work though for trivial reasons, easy to identify and fix.
I made an initial try to contact SiNaN. SP has considered a license change, but in my understanding from Eliana, they haven't contacted yet previous contributors.
Haven't waded through all the IRC logs. tl:dr; :P
Not sure what current TP code is like. Brad reckons it's a lot cleaner than it used to be. It has more functionality than is really needed, but some people will like that. Dunno what the licensing situation is. I suppose Brad would be into an Elk version if the coders can be found to do the work (Earth calling Brad).
SP code is basically good, but the only catch is it doesn't really have any provision for articles and categories thereof. You could sorta fudge it with enough manual coding if you're crazy enough, but that's out of the reach of most users and a PITA even for proficient coders. I vaguely remember talking with Elkiana :D about this stuff. Articles/categories system was planned but not coded.
Just, remember the way to disable it completely (and I mean no traces of the portal if disabled, I don't want any portal on my forum :P).
Yeah yeah yeah yeah. I was actually thinking of it as a mod rather than as part of the default installation. As long as it exists and works, that's ok. Being totally without one and just producing a basic form app would, IMO, not be enough.
To put it bluntly, if I want something I can use on the site I run. If I'm not going to get that, I'd be better off looking for other software. However, since I'm not the only perosn who will want a portal anyway........................................
Well, if the issue is just have a portal available, I don't see any big issue in adapting one of the existing (i.e. SP like I did locally for testing a while ago before the moving-around-files phase) to work with Elkarte, of course it's almost useless do it now because things are still changing, it may be reasonable to focus on that once we have a beta.
Instead if the intention is to have a portal included in the distribution from the start, we'd have to work on it before the beta.
At that point I'd vote for "add-on" and (in case) after the release pack the two together in one download (along with a "without-portal" version) for better flexibility.
Oh, and please: "php" blocks, articles, whatever strictly "admin-only", without any permission. It's useless to close tiny holes if then we let non-admins use any php code. O:-)
And it would be nice to have HTML "admin-only" too.
Oh sure. I'm not into letting any old user write blocks. That would be silly. Block setup definitely comes under site administration.
Well the last I heard was that SP was being considered. I haven't really touched TP code lately, except to fix some trivial things. TP's code state is such that it needs quite a bit of re-factoring. It could certainly be fixed or updated much like SMF's => Elkarte has happened. But that means it falls to those who want to do it. It needs a lot of things IMO. So basically it comes down to this with TP and SP.
TP - already licensed appropriately. Ready to be integrated, updated, re-factored if people want to. Quite a bit of work IMO. I could certainly make it work with Elk with minimal effort and release it as a mod.
SP - will need a lot less re-factoring or fixing the code. But isn't licensed appropriately yet. Not as much work, but how long if at all, will it take to get the appropriate license on it? According to some, lacks in features that would be wanted.
I'm ok with either really. But how many Dev's here give enough crap to actually want to work on this? Is there enough interest that this could be done? Ant won't be coding the backend, I'd be interested in helping. But I don't really see other folks wanting to put this on their plate. Maybe I don't know what I'm talking about either. lol
Yeah I don't mind templating it if that's required, but can't do a lot of the back end. Wouldn't be interested in SP unless it's going to have a real articles system added. Without that, it's no use to me. If that is added, then would be fine with working on it.
You already have the forum, why do you want/need an article system? ???
Like Norv would say, you just have to set a different theme for a board and that's all (and you set the permissions to "no-reply" to cut down the issue of the first post not displayed on each page (otherwise it is just the matter of retrieve one more message from the database at each page load, nothing scary...it may even be possible without code edits on Elk/2.1, since there is a hook somewhere around there, don't remember the details)).
If you want to hide that board from the normal board/messageindex of SMF, you make it child-board of a board regular members are not allowed to view and you have your forum clean.
You can already fool the system! :P
In the worst case you (in the sense of "someone", not you directly, I know you are a lazy designer) can code an action to show results of a certain board kept invisible (i.e. disallow) to everybody and mimic an "article" or similar things.
And that would also have the gigantic advantage to allow to get results from searches on both posts and articles at the same time.
Of course unless you with "article" mean something completely different that I have no idea about, and if so:
/me needs more details.
That's not the case for almost any portal out there: all the current portals have a separate permission that may allow other groups to be able to add blocks or articles in php, that's something I highly dislike.
Yeah I know, but I think in practice any sane admin will limit it to admins or other staff members. Like I allow global mods to edit some things, because we trust our mods. None of them are interested in messing around with PHP. The only real difference between them and the admins is that they have less stuff to worry about.
Because forum posts aren't that good a format for some things. Dedicated pages are better.
PHP articles can do a lot more than posts or topics. Custom pages is not the only use for articles either. I'd rather not mix the two. Articles tend to have a lot more customize-able options than a topic. To me, using a topic as an article is like saying I can drive VW Bug instead of a Veyron because they both have wheels and seats... Now in hopes of not getting in a semantics debate about articles vs topics, let's just say people requested it enough to make it worth it. SP had done a fantastic job using topics, but yet their users have always wanted an article system. Whether we understand all the reasons or not, it's what people wanted.
What he said. :)
/me doesn't really care about what others want, but just what eh likes. :P
Mostly because what people think to want is not what they really want.
Well, if I could understand how an "article" is actually different from a post I would probably be more interested in create yet-another-piece-of-duplicated-code.
If the only issue is the interface it's just a matter of changing a menu entry (like I did on a site I set up renaming the menu entry from "forum" to "articles" and adding a 2nd level menu with "new article" and the "Post_Board_Select" mod).
Welcome to the club. :P
Several ways. For a start, you don't have all the crap associated with posts. Userarea area, sigs, etc. This means cleaner presentation of content, which is important sometimes.
Also, since an "article" is basically just a wrapper for a custom html page, you can do what you damned well like on it. Also, if you give a rat's, it's far cleaner in terms of code and performance because you're not running everything through parse_bbc.
Could the same content be presented as a series of forum posts? Sure it could, but for some purposes it would be a crappier format.
There is a very good point here, cross-posts in this thread. (even when you folks seem to disagree :) )
We move towards extracting commonalities between kinds of content. Create better prototypes of a 'post' or 'article', refactor or write/rewrite their functionality in terms of an API, and allow the prototype(s) to serve both, but distinguish their available features.
Some of it might be part of our current refactoring. (or might not enter; we don't really plan on which item, with a few exceptions, we want to work, but in general on 'items that have redundant code, etc', so we might get to a specific case or not).
We will be back on this after 1.0 stable release, be sure.
For the moment, lets clarify one thing here, please:
Portals (and SMF mods) are easy to update to Elk. The issue "do we have portals" is a non-issue. Yes.
On the other hand, personally, more than a simple update, I understand an integration in Elk or a full refactoring of portals isn't a good idea nor an interesting idea to people. That's okay.
I suggest we make a few test runs soon - say in a couple weeks, to test and update them. TP is on github, find it, test it, propose a pull request, report issues to Brad. ;)
I assure you that was completely unintentional, and wont happen again. :P
lol. Well at SMF this would have already been a drama topic that reached page 10 at this point in any discussion about such things. So to see this kind of discussion from reasoned individuals is a bit of fresh air if you ask me. Would be great to have a createPost() function that could be wrapped into the API to post articles. Things like that would make portals have a little less code. :D
How do you envisage that function working, in rough terms?
Well I hadn't fleshed out the idea yet really. But can definitely use it to do a BBC article. Even an html article. And even though I'm no veteran coder, it would be nice to see it be able to handle more parameters for article options, that could use call back functions to handle such things. If that makes any sense to anyone. For all I know I could be speaking Taiwanese... ;)
Different theme.
/me whistles innocently.
Ohh...then you are talking about posting HTML, not about "an article system".
And far less secure unless you sanitize the code (and remove anything that is not simple html, already allowed in posts too using the html tag).
I agree that in order to be able to have easy and nicely formatted pages, some tags are missing,
Having some more tags (for example h2/3/4/5/6) we could even create TOCs the way wikimedia does, or just some more attributes to existing ones would allow better formatting (float for images, width for tables, etc.).
No, not a different theme. People don't want to have to code and install more themes when they want a couple of portal pages. :P
HTML includes articles. They can be HTML or PHP. They can be used for what you'd think of as articles, or for custom pages, or both.
Not less secure, if done properly.
Why more tags? That's just bringing you back to running everything through parse_bbc.
And you're still not talking about all the other stuff portals do. :P
If you create a different theme and make it so the topic is shown as a "page", 99.9% of the people will not notice the difference.
You said that people don't care about the back-end (Nov. 2012 :P), and I can add they just want to see what they think they want.
Heck, I have to finish the "building_blocks" branch.
Then you have to maintain: preparsecode, parse_bbc and another parallel code to "properly cleanup" HTML (and you have to remove several...well, you have to leave in place only few things if you want to do it properly).
Apart from the fact that PHP will never ever be secure, but that's another issue.
Oohhh...FFS!
Do you know how many times parse_bbc runs in a normal topic page?
I'll give you a hint:
1 time for the news
1 time for each message,
* 1 time for each signature (one for each user).
If you have 20 messages from 20 different user it means 41 times.
You are talking about 1 (one) message (it may be long, but that' doesn't make much difference) alone in a page. How much do you think it will impact on the server load? I'll give you a hint: less then 1 (one) single query of 1 (one) single member running unread replies with a week of unread messages.
And you have the advantage of consistent styling (no need to re-define styles for articles when links wouldn't have the "bbc_link" class attached, for example), you don't have to care about cleaning up the HTML (preparsecode will do it just fine for
you us), you now even have a good WYSIWYG editor (so styling is not an issue).
So, the only thing missing is some fancy styling of some part of the text if you need it.
Dunno...I see a slightly more flexible parse_bbc would be much more helpful than HTML, but that's just me. :P
I'm not arguing against portals, that's why I'm not talking about other things. :P
I'm trying to understand what an "article" is in your head. O:-)
I can't see the "different theme" working at all. Obvious scenario: a site that offers more than one theme. If you can come up with a way of automatically assigning consistent styling regardless of which theme the user has selected, then I'll consider "different theme for articles". Otherwise, it's a dead duck.
Ok, but since portals already have this code anyway.........................................
Ok, now you're starting to make sense.
https://bitbucket.org/spuds_/elk_simpleportal
By the by, SP is definitely changing our license for the next release to be friendlier. Stay tuned.
Great work! Really glad to see Elk SP.
The portal was one of the core needs for Elk. The sky is the limit now. ;)
As I said elsewhere, I suggest to make a github clone. Git hooks can keep synchronized.
This thing needs tableless markup. :)