Advertisement:

Author Topic: Functionality requests for SSI in the next version of SMF  (Read 96106 times)

Offline Daniel15

  • SMF Friend
  • SMF Hero
  • *
  • Posts: 4,222
  • Gender: Male
  • http://dan.cx/
    • daaniel on Facebook
    • Daniel15 on GitHub
    • daniel15 on LinkedIn
    • @Daniel15 on Twitter
    • Daniel15
Re: Functionality requests for SSI in the next version of SMF
« Reply #20 on: January 17, 2007, 11:19:18 PM »
Nice work, bpat1434 :)
Just a few things:
Code: [Select]
if(count($topic_ids)>1)
$wclause = "m.ID_TOPIC IN (" . implode(', ', $topic_ids) . ")";
else if(count($topic_ids == 1))
$wclause = "m.ID_TOPIC = '" . $topic_ids[0] . "'";

$request = db_query("
SELECT m.subject, t.ID_TOPIC,
t.ID_LAST_MSG
FROM {$db_prefix}topics AS t
LEFT JOIN {$db_prefix}messages AS m
ON t.ID_FIRST_MSG = m.ID_MSG
WHERE " . $wclause, __FILE__, __LINE__);
It should still work properly if the IN only has one ID in it, so something like this should still work:
Code: [Select]

$request = db_query("
SELECT m.subject, t.ID_TOPIC,
t.ID_LAST_MSG
FROM {$db_prefix}topics AS t
LEFT JOIN {$db_prefix}messages AS m
ON t.ID_FIRST_MSG = m.ID_MSG
WHERE m.ID_TOPIC IN (" . implode(', ', $topic_ids) . ')', __FILE__, __LINE__);

:)

Another minor thing:
Code: [Select]
if (strlen($row['body']) > 512)
$row['body'] = substr($row['body'], 0, 512) . '...';
SMF has a different way of doing this, which ensures that it doesn't cut the text off in the middle of a word or <br /> tag. It trims it to the nearest word. I can't remember the code, though

Quote
You can see this in action at www.roundcubeforum.net
You're the owner of www.roundcubeforum.net? I love Roundcube, it's got to be one of the best webmail programs. I've integrated it into my cPanel :D
« Last Edit: January 17, 2007, 11:31:23 PM by Daniel15 »
Daniel15, former Customisation team member, resigned due to lack of time. I still love everyone here :D.
Go to smfshop.com for SMFshop support, do NOT email or PM me!

Offline B Patterson

  • Full Member
  • ***
  • Posts: 512
  • Gender: Male
  • Never Miss an Opportunity to be Great
Re: Functionality requests for SSI in the next version of SMF
« Reply #21 on: January 17, 2007, 11:28:15 PM »
I'm the operator and owner of www.roundcubeforum.net; however, I'm not the lead developer.  I'm just an avid user of RC and wanted to help out, so I created the forums.  You should join Daniel (if you haven't already).  I'm sure you could lend some advice to our not-so-technically-inclined visitors.... plus the look of roundcubeforum.net is going to change drastically.... I can't wait.  I get started tomorrow.  All the mods I've done in the past week have been for SMF for RCForum.... although I plan on releasing them generally.  None can be put in SSI.php though... pity...

Offline Ensiferous

  • Full Member
  • ***
  • Posts: 601
  • Gender: Male
    • Nginx, PHP and Site Management
Re: Functionality requests for SSI in the next version of SMF
« Reply #22 on: January 30, 2007, 01:08:33 PM »
Personally I'd work on getting better performance before implementing more features. First of all the require/include_once does not go well with an opcode cache, and smf should really be coded probably to not have to use it and instead use require/include. Granted, users might mess it up, but it could speed things up a bit.

Oh and here's some proof in forms of images of a cachegrind analyse.

« Last Edit: January 30, 2007, 01:14:40 PM by NoFear »
My Latest Blog Post: Debugging Nginx Errors

Offline B Patterson

  • Full Member
  • ***
  • Posts: 512
  • Gender: Male
  • Never Miss an Opportunity to be Great
Re: Functionality requests for SSI in the next version of SMF
« Reply #23 on: January 30, 2007, 04:20:41 PM »
Why not use require_once or include_once?  They're there so that you can't accidentally " re-declare certain functions or overwrite variables inadvertently.  It's no slower than require, and no faster.

Offline Ensiferous

  • Full Member
  • ***
  • Posts: 601
  • Gender: Male
    • Nginx, PHP and Site Management
Re: Functionality requests for SSI in the next version of SMF
« Reply #24 on: January 30, 2007, 04:29:10 PM »
I beg to differ. Logically it would be slower as it has to check if said file has already been included, however, that's marginal. What I actually said was it was slower when used with an opcode cache. Since you have no reason to believe me I'll send you to talks.php.net

Rasmus Lerdorf (php creator): http://talks.php.net/show/oscon06/8

"This is because include_once and require_once don't play nice with opcode caches right now. Changing to require brings us to 875 requests/second."

But that was merely one little thing I noticed from the quick profiling I did. There are probably larger issues at hand.

And in the future, if you're going to disagree on a subject it's smart to do some research, the other person might just know what he's talking about.
My Latest Blog Post: Debugging Nginx Errors

Offline B Patterson

  • Full Member
  • ***
  • Posts: 512
  • Gender: Male
  • Never Miss an Opportunity to be Great
Re: Functionality requests for SSI in the next version of SMF
« Reply #25 on: January 30, 2007, 05:03:59 PM »
Okay, I wasn't saying you were wrong.  I was just saying that to my understanding require_once/include_once were just as fast, or only a few milliseconds slower than require/include.  Never said I was the authority on the issue.

I wasn't aware of what exactly opcode cache was, so I read up on it.  Now I know, now I stand corrected.  Sorry for asking a question....

Offline Ensiferous

  • Full Member
  • ***
  • Posts: 601
  • Gender: Male
    • Nginx, PHP and Site Management
Re: Functionality requests for SSI in the next version of SMF
« Reply #26 on: January 30, 2007, 05:25:07 PM »
Sorry if I may have come off as being a bit arrogant, that really wasn't my intention. The issue that the SSI file could use some optimizing is still standing though. The smf_api.php file is great if you don't need fancy theme stuff, he blazing fast and will work with only minor modifications.
My Latest Blog Post: Debugging Nginx Errors

Offline B Patterson

  • Full Member
  • ***
  • Posts: 512
  • Gender: Male
  • Never Miss an Opportunity to be Great
Re: Functionality requests for SSI in the next version of SMF
« Reply #27 on: January 30, 2007, 05:37:17 PM »
I agree, SSI.php could use optimizing now too.  Now that I'm aware of exactly how "slow" it really is.

Offline Daniel15

  • SMF Friend
  • SMF Hero
  • *
  • Posts: 4,222
  • Gender: Male
  • http://dan.cx/
    • daaniel on Facebook
    • Daniel15 on GitHub
    • daniel15 on LinkedIn
    • @Daniel15 on Twitter
    • Daniel15
Re: Functionality requests for SSI in the next version of SMF
« Reply #28 on: January 30, 2007, 08:54:35 PM »
NoFear, what utility are you using to profile the PHP script? It looks quite useful :)
Daniel15, former Customisation team member, resigned due to lack of time. I still love everyone here :D.
Go to smfshop.com for SMFshop support, do NOT email or PM me!

Offline Ensiferous

  • Full Member
  • ***
  • Posts: 601
  • Gender: Male
    • Nginx, PHP and Site Management
Re: Functionality requests for SSI in the next version of SMF
« Reply #29 on: January 31, 2007, 02:01:23 AM »
I'm using the plugin Xdebug which generates a cachegrind file that can be analysed with kCacheGrind for linux or WinCacheGrind for windows. And it is very useful indeed.



Edit: Fixed broken url tag - Motoko-chan
« Last Edit: March 29, 2007, 07:31:25 PM by Motoko-chan »
My Latest Blog Post: Debugging Nginx Errors

Offline Vanscot

  • Semi-Newbie
  • *
  • Posts: 51
  • Gender: Male
    • Proyecto Yamato
Re: Functionality requests for SSI in the next version of SMF
« Reply #30 on: February 08, 2007, 08:45:39 AM »
Well, I'll add a little bit here:

1 Originally was:

function ssi_welcome($output_method 'echo')
{
        global 
$context$txt$scripturl;

        if (
$output_method == 'echo')
        {
                if (
$context['user']['is_guest'])
                        echo 
$txt['welcome_guest']; 
                else
                        echo 
$txt['hello_member'], ' <b>'$context['user']['name'], '</b>',
allowedTo('pm_read') ? ', ' $txt[152] . 
' <a href="' $scripturl '?action=pm">' $context['user']['messages'] . ' ' 
(
$context['user']['messages'] == '1' $txt[471] : $txt[153]) . '</a>' 
$txt['newmessages4'] . ' ' $context['user']['unread_messages'
' ' . ($context['user']['unread_messages'] == '1' $txt['newmessages0'] : $txt['newmessages1']) : '''.';
        }
        
// Don't echo... then do what?!
        
else
                return 
$context['user'];
}


My idea:

function ssi_welcome$output_method 'echo' ) {
	
global 
$context$txt$scripturl;

	
if( 
$context['user']['is_guest'] ) {
	
	
$buffer $txt['welcome_guest'];
	
} else {
	
	
$buffer '<a href="foro/index.php?action=profile;u=' .
	
	
	
  
getUserID$context['user']['name'] ).'">' .
	
	
	
  
$context['user']['name'] . '</a><br />';
	
	
if( 
allowedTo'pm_read' ) ) {
	
	
	
$buffer .= 'Tienes ' .
	
	
	
	
   
' <a href="' $scripturl '?action=pm">' .
	
	
	
	
   
$context['user']['unread_messages'] . ' ';
	
	
	
if( 
$context['user']['unread_messages'] == '1' ) {
	
	
	
	
$buffer .= ' mensaje';
	
	
	
} else {
	
	
	
	
$buffer .= ' mensajes';
	
	
	
}
	
	
	
$buffer .= '</a>';
	
	
} else {
	
	
	
$buffer .= '.';
	
	
}
	
}
	
if( 
$output_method == 'echo' ) {
	
	
echo 
$buffer;
	
} else { 
// Don't echo... then do what?!
	
	
return 
$buffer;
	
}
}


To put it clear, If I dont want something outputed (echo, print, etc) maybe i want it returned.
(array, var, string or bool return, so I can use it somwhere else.)

2 I would use a different approach to templates.
Here where I work, we use a like this:

<?php
//this is index.php
//logic and data processing.

include( template'../templates/index.html' ) );

index.html looks like:

<html>
etc, etc,

<body>
{$variables_to_show}
Web structure.(tds, p, h1, etc)
</body>

</html>

The dirs looks like:

./include where functions and reusable stuff lives. (Hopefully, html, _SESSION, globals free functions)
./templates where all the templates lives.
./web where all the .php scripts are waiting to be called.

It's a nice and clean way to see the world and know what to change and where to change.
Maybe you can use that.
« Last Edit: February 08, 2007, 09:15:36 AM by Vanscot »



Offline Sindorf

  • SMF Hero
  • ******
  • Posts: 1,635
  • Gender: Male
    • My personal website, with its own shape and taste :)
Re: Functionality requests for SSI in the next version of SMF
« Reply #31 on: February 08, 2007, 03:26:51 PM »
It would be better to add an option to SSI like grabbing topics (and/or messages maybe) in a single board using the output style of the function ssi_recentTopics. It becomes very hard to exclude_boards in ssi_recentTopics(); when you have over 50 boards :) Also exclusion have some problems (if you exclude all boards except one board, ssi_recentTopics shows a single message)

I will try to work on this type of function in a few weeks, but if anyone have such a system or have more time to work on this type of system, it will be welcomed! :)

Thanks. :)

bank robber

  • Guest
Re: Functionality requests for SSI in the next version of SMF
« Reply #32 on: February 12, 2007, 02:30:06 PM »
SMF IMHO, needs to be re-architectured heavily. PHP has support for classes now, using arrays and not having centralized load/save methods...is like zomg.

One of the functions I would like to see is centralize functions for Board, Post,Category. Sort of like convert the SSI to a centralize API.

in the SSI, have methods to modify a post, board, or category or any other object etc. It should all be centralized etc.

Offline Daniel15

  • SMF Friend
  • SMF Hero
  • *
  • Posts: 4,222
  • Gender: Male
  • http://dan.cx/
    • daaniel on Facebook
    • Daniel15 on GitHub
    • daniel15 on LinkedIn
    • @Daniel15 on Twitter
    • Daniel15
Re: Functionality requests for SSI in the next version of SMF
« Reply #33 on: February 13, 2007, 03:18:10 AM »
Quote
PHP has support for classes now
Yes, but the class handling differs in PHP 5 compared to PHP 4 (look at JpGraph for instance -- It has two seperate versions, one for PHP 4, and the other for PHP 5).

Quote
One of the functions I would like to see is centralize functions for Board, Post,Category. Sort of like convert the SSI to a centralize API.

in the SSI, have methods to modify a post, board, or category or any other object etc. It should all be centralized etc.
SMF 1.1 started this (the createPost() function, etc), and it will be improved heavily in SMF Development Edition. I believe that all the main functions will be split into seperate PHP functions, making things like this a lot easier ;)
Daniel15, former Customisation team member, resigned due to lack of time. I still love everyone here :D.
Go to smfshop.com for SMFshop support, do NOT email or PM me!

Offline Lastwebpage

  • Semi-Newbie
  • *
  • Posts: 33
Re: Functionality requests for SSI in the next version of SMF
« Reply #34 on: February 28, 2007, 07:46:23 AM »
Hello,
for some "external" websites, like wikis for example, or external "apps" like a Vista sidebar gadget, it would be usefull to get the search results somewhere, for example:
ssi_searchPosts("Search String",10); give me the first ten search results, in the form
< a href="Link to article">Topic</a>, or 10 link/title pairs if I use the array method.

I am not sure if this should be in the SSI, but for me this is the correct place for this.

Peter  

Offline Lastwebpage

  • Semi-Newbie
  • *
  • Posts: 33
Re: Functionality requests for SSI in the next version of SMF
« Reply #35 on: March 10, 2007, 04:39:04 AM »
One more:
an equivalent to boardNews for recentTopics, recentPosts
or/and a method to get a message (topic=1414;msg8989) back from SSI as "plain HTML", like the output from boardNews.

Both things throught URLs NOT throught "php only" functions.

Offline Lastwebpage

  • Semi-Newbie
  • *
  • Posts: 33
Re: Functionality requests for SSI in the next version of SMF
« Reply #36 on: March 14, 2007, 08:49:05 AM »
the 3rd...
ssi_quickSearch($text); not only with this form element, because it fails with not PHP sites too.

Offline twistedsymphony

  • Semi-Newbie
  • *
  • Posts: 26
Re: Functionality requests for SSI in the next version of SMF
« Reply #37 on: March 14, 2007, 10:10:46 AM »
I've only been working with the SMF integration tools for about a month now and honestly I want to punch myself in the face and rip out my skull after the number of roadblocks and work around I've had to over come just for the simplest of tasks when integrading with other systems

1. prefix your functions - I've found no less then 5 SMF functions that conflict with other functions of the system I'm trying to integrate... I've told them to prefix their functions and now I'm telling you... it's just good practice when you're trying to develop an open ended system, you have no idea how many headaches this causes. if everyone prefixes then it makes for a happy developer.

2. instead of functions executing some code maybe they could just return a result, or result set. For instance ssi_showPoll() grabs the poll data, puts it in a table and then echos the table... if I want to tweak that data before I display it there's not much I can do. since the data is echoed from the function I cant analyze it or modify it I have to just let it display. which means the only thing I can use to control it is CSS. This is a problem also since the table is lacking any kind of identification, particularly because I have no way of knowing whether I've received poll options or poll results and I'd need different CSS depending on which one I've got. A much better option IMO would be to return the poll data as an array then I can do whatever I want with it... if you want to keep it simple so people can just plug in a function and get a tabelized poll fine maybe the poll function could have some options like sending a $format='T' returns a table 'A' returns an array and 'L' returns it in the much more CSS friendly List Item format. at very lead give me an id to work with.

I'd like to have this kind of flexibility with all of the data functions... give me an array with the results so I can do what I want with them.

3. Give me some options to put data INTO SMF.. not just take it out. I don't think it's too much to ask for a simple function where I can pass an array containing the user id, board id, post icon, title and content of a post and have it just show up on the forums.... or do that with a poll... or do that with a new news item... or do that with a new user to be registered... or do that for a user login... or any other function where I'd put information INTO SMF.

4. triggers: some way to have a function of mine triggered when something happens... when a new post is created, a new topic is created, a new user registers, the news changes... fire off my function so I can do something.

If you want to take this one step further this could be useful for plugins... except maybe it would intercept the data between the UI and plugins... so if a user creates a new topic... the topic data would be sent to my custom function FIRST then my function would return the same data after it was done doing its thing... Probably beyond the scope of SSI.php though.

WAY BEYOND THE SCOPE OF SSI.php:
IMO the most flexable applications are the ones that build an engine with an API and then build the UI using their own API... that way anyone can do anything through the API. and you could even trash the stock UI completely for something completely custom if you so desire.

While I know this kind of thing would be extremely difficult to do at this point the concept is important... think about the kind of things the UI needs to do when communicating with the rest of SMF... and give us that kind of control through SSI.

Offline Ben_S

  • SMF Friend
  • SMF Super Hero
  • *
  • Posts: 11,725
  • xxx
Re: Functionality requests for SSI in the next version of SMF
« Reply #38 on: March 15, 2007, 09:13:35 AM »
1> I beleive thats being worked towards with the next release.
2> SSI.php is already capable of returning the data as an array, eg ssi_boardNews(2,8,0,50,"array")
3> Use the createPost function <http://support.simplemachines.org/function_db/index.php?action=view_function;function=377> Include SSI.php, require sources/Subs-Post.php and away you go.
 
Liverpool FC Forum with 14 million+ posts.

Offline Joshua Dickerson

  • SMF Friend
  • SMF Super Hero
  • *
  • Posts: 12,777
  • Gender: Male
    • joshuaadickerson on GitHub
    • joshuaadickerson on LinkedIn
Re: Functionality requests for SSI in the next version of SMF
« Reply #39 on: April 08, 2007, 05:32:51 AM »
Personally I'd work on getting better performance before implementing more features. First of all the require/include_once does not go well with an opcode cache, and smf should really be coded probably to not have to use it and instead use require/include. Granted, users might mess it up, but it could speed things up a bit.

Oh and here's some proof in forms of images of a cachegrind analyse.


Sorry for reply to such an old post, but I have been profiling SMF myself for a while and I didn't notice similar results. Are you using relative paths?
Need help? See the wiki. Want to help SMF? See the wiki!

Did you know you can help develop SMF? See us on Github.

How have you bettered the world today?