Joomla! Discussion Forums

Sorry for the new topic, but the other is locked.

This isn't yet solved.  The solution offered was entirely virtual, without any practical application yet.

I've discussed this with the other SMF devs, and there are other issues involved in forcing obExit to return instead of exit.

obExit sometimes gets called from a function named is_not_guest.  This function is used in cases like the PMs (not the only example, but the example I will use to explain). 

is_not_guest checks to see if the user is logged in.  If the user is logged in, it returns.  If not, it loads the login template, and calls obExit to exit without returning to the PM page-rendering.

Now, if obExit returns to is_not_guest, then is_not_guest will return to the PM page-rendering, and despite the error message generated by a guest trying to access PMs, the PM page will be displayed anyway.

I suppose the good news (?) is that it would render it inside Joomla....but it wouldn't be secure. 

There may still be one way, but it will take me some time.  The code I posted in the other topic would be what I would be attempting to make work, as I said, by adding in the code that would normally happen after the component execution.  Now. please note that I say may be a way, as long as I can in fact wrap all that up inside a function in the component. 

To the Joomla devs:  If there is a way to create a function in Joomla 1.5 that would wrap all the code that is executed after the component output, it would help an awful lot.

Hi Orsatio,



No problem, let's use this thread to start fresh.



This is a problem indeed. It means under these circomstances we cannot delay the exit using an event handler in Joomla! 1.5. 

As a side note, it feels a bit strange that a function called 'is_not_guest' could force a script to exit. Wouldn't it be better to let it return a boolean to inform the caller if the user is a guest or not. Let the caller then decide what he needs to do with that information. This would definitly make the function alot more flexible and universal.



While this technically could be done, it feels very unnatural. What you would be doing is allowing Joomla! to boot up, starts it's application flow and right in the middle you would interupt it, let your smf component take over and from that point your component and not Joomla! would drive the execution flow. That's smells a bit like appliaction hijacking to me.

I think that this solution should only be looked at as the worst case scenario.. By letting smf taken over you would be mixing two security models and you could potentially run into BC issues in later releases of Joomla! 1.5.x as the point where you take over could change up or down resulting in a needed change in your code.

I think that you should strive to a solution that doesn't require you to hijack Joomla!. I ca, see two possible options, either Joomla! drives the application flow, or SMF does. Or said otherwise, you either integrate SMF into Joomla! or you integrate Joomla! into SMF.

You could try exploring to do something like a special entry file that would fire up SMF and integrate Joomla! in it. You could derive you own JApplication class  much like the JSite app. In this case SMF would be in full control of the excution flow and could decide to exit at any time. Just an idea ...

We are discussing that for future versions.  There are a number of points that make it more flexible to return a boolean, and less prone to people who like to tinker with the code inadvertantly opening up a security hole for themselves.  It would also allow for the workflow to fall through SMF instead of needing to exit, facilitating the return to Joomla nicely.  This also solves the issue I had with PostNuke, so I would be able to continue with that integration as well.



That's correct.  It does seem odd, but it is how the bridge for Mambo 4.5.x and Joomla 1.0.x has worked until now.



Yes, that's already happened in past releases.  It's not nearly as painful as it seems, though, as it's a matter of telling people they should upgrade.



I think with what we (SMF devs) are talking about for the future of SMF will be the best choice, all around.  However, it means that bridging with Joomla 1.5 will wait until after SMF 1.1.x, if I can't get the "hijacking" code to work.

[Mod note; tagged for tracking]

So, hijacking it will be. The best solution to hijack the flow in a very BC way would be to use one of the onAfter... events. If you want to interput the flow right after the component is called you best use onAfterExecute, but you could probably also use onAfterDisplay too. onAfterExecute is triggered after the application has been executed but before anything is send to the browser. You can have a look at the execute function in JSite::execute() (includes/application.php line 80). At this point all that has happenend is that the  component has been called and the output has been pushed in the JDocument buffer.

As we explained before you would do something like :



All you then need to make sure is that the hijackApplication function contains the following code :



That should be all. Give it a whirl and see if it does what you need it to do.

Johan

Hi-

I am trying to convince myself to start a major development using 1.5-

If I do use 1.5 (over Drupal 5) I will have my team of coders bridge SMF-

If I can get considerable HELP and pointers then this would help my coders. They are not familiar with Joomla and I dont want to waste too much time. So I will pay for the bridge to be built if some people here give me as much details as possible on what exactly needs to be done to get this built the right way with 100% features working together.

Thanks!

OK, this works with beta 2, sort of.

The errors and admin panel do stay wrapped in Joomla URLs, which is a good step forward.  :D

Unfortunately, I get this error:



This is what I have on line 160 (from the code above):



This would indicate to me that there is no display method in the $mainframe object at this point in the workflow...

And, this may or may not be related, but the forum, while wrapped in the Joomla URL and context, does not display the Joomla template.

I'm sure I can track this down, but any help would be appreciated.

What is line 160 supposed to do?

I'm not aware of any JApplication::display() method...  maybe it is gone, but I don't recall it ever being there.

Ian

Actually, I've already solved that by doing this instead:



And adding SMFViewSMF and SMFController classes to conform to Joomla's MVC structure.

The only thing I have yet to contend with here is dumping the output into the Joomla template.  Otherwise, the wrap is good -- SMF stays within the Joomla context in all cases, so the integration is valid without alteration of codebases.

OK, I figured out how to dump the forum output to the template.  Now a full wrap in Joomla context and template. 

Now, I just need to load the appropriate modules before display. 

Again, any help would be appreciated.

Hi Orstio,

I cannot really help, but this is just to say that I'm glad you're finally in a situation where you're making progress on this.

Thanks for the efforts.

Richard.

If I do this:



Should that not display the text "Hello World!" to the template where the top modules should be?  I'm getting nothing, so I'm thinking there's something I'm not seeing....

Sorry to bump this...

I still haven't been able to figure this out, and could use some assistance.

should...  Can you trace at all what is happening?  Are you sure that you're getting a JDocumentHTML object?

Ian

Well, just before that, I have this:



Which is working to display the output of SMF (in the variable $buffer) in the component placeholder.

Thanks for the reply, and thanks for the MVC component tutorials.  They were very helpful in creating this so far. 

And what happens if you do a print_r( $document->_buffer ); ?

This should give you some info as to what is going on...  from that you should be able to check that the data is indeed getting into the buffer...  If that is the case, then we can narrow it down a little bit...

Ian

Heh, then it says this:



Followed by the forum output, and then

Is get buffer getting called with the right parameters?  Where is the data getting lost?

Can you modify the getBuffer method to echo its output?

Ian

I may be modifying the wrong file here.  The only getBuffer method that seems appropriate is in libraries/joomla/document/document.php.  Is that the right one?

After getting no output from an echo in the function, I changed it to this, actually:



Which should end execution, and it doesn't (not even on the frontpage component), so that method is never in the workflow.

First time working with OO code it looks like

JDocument is using a template pattern, most of it's methods are overridden by the extended classes. In this case you might wanna try to play with the getBuffer method in the JDocumentHTML class.

Not the first time working with OO (I do some work with Java as well), but definitely the first time with so many class extensions on top of class extensions.  THat, and for some reason my text editor "Function List" plugin doesn't like the word "render" for some reason, and so some functions in the Joomla code aren't showing up in the function list.

Thanks for the direction;  This has gotten me to this point:

This code yields nothing:



Yet, in exactly the same place, this works:



Any ideas?

Here is the getBuffer method that should be getting invoked:

JDocumentHTML::getBuffer():


function getBuffer($type, $name = null, $attribs = array())
{
$result = null;
if(isset($this->_buffer[$type][$name])) {
$result = $this->_buffer[$type][$name];
}

if( @ $renderer =& $this->loadRenderer( $type )) {
$result = $renderer->render($name, $attribs, $result);
};

return $result;

}
Now looking more closely, this will invoke the render method anyway and relies on the renderer to render the method.  Do you have any modules published in the top position?

Ian

P.S.  @Jinx: Is this the intended behaviour?  I would have thought that if the buffer is already set, then it would return that as the result.  If it isn't set, then it should try and use the renderer to render the module.  Perhaps there should be a return $result inside the first if statement?

You got it ianmac!

Changing the getBuffer function to this makes it work:

yeah...  I'll make a note of this to Jinx to see if this is what it is intended to be.

Ian

The method is correct, to understand what happens when the buffer is already set you need to have a look at the respective render methods of the different renderers.

I got it. 

Jinx is correct -- the method is correct.

Thanks for all the help.

For future reference, the problem was that SMF switches to using its own database, and I hadn't added the switch back to the Joomla database before trying to output, which means that none of the values were pulling from the database.  After starting up the JConfig object, and switching to the Joomla database after creating the SMF output buffer, all is well.

We have a full bridge. 

http://www.everything-science.com/devte ... on=com_smf

Again, thanks very much for all the help.  It really was invaluable, and pointed me in the right direction to find the root of the problem.

Way to go all of you! 

Do we have a test release?

When is Orstio going to write the new ACL system for Joomla?

I was under the understanding he would have it ready next week ?