No Bridge for Joomla 1.5

[terox]

You will have to excuse my newbiness lack of knowledge here.

It would seem that the main issue for the J1.5-smf bridge is to do with wrapping smf inside joomla

As smf is designed to be standalone, would it be simpler and easier to make a bridge version that was designed to simply allow 1 login/registration to access both for non wrapped smf

design of templates for the two apps could then be used to satisfy the cosmetics

[Orstio]

As smf is designed to be standalone, would it be simpler and easier to make a bridge version that was designed to simply allow 1 login/registration to access both for non wrapped smf

That would require, at the very least, modifications to SMF.  That would be a modification package, not a bridge.

[terox]

can SMF use an add on to it's login system to send 2 cookies, one for the smf login and 1 for the joomla login? And can it do that without having to change the core files?

apparently joomla can do this

[Orstio]

can SMF use an add on to it's login system to send 2 cookies, one for the smf login and 1 for the joomla login?

Yes.

And can it do that without having to change the core files?

Not without a bridge structure to support it.

[terox]

Thx for the reply

[xtremecruiser]

Ironic that Joomla forums are SMF - surely they must be aware of this issue for many users...

Indeed that is ironic

[shawn122]

not very ironic...the SMF forums at joomla are standalone--not bridged in anyway with joomla.

[elfishtroll]

As smf is designed to be standalone, would it be simpler and easier to make a bridge version that was designed to simply allow 1 login/registration to access both for non wrapped smf

That would require, at the very least, modifications to SMF.  That would be a modification package, not a bridge.

far be it for me to correct the original bridge author

but isnt there a SSI_Login/Logout function in SMF (ssi_php) so that  all you need to do on the Joomla side for minimal functionality: ie. Single Login is to just log in via Joomla, then, when  the page refreshes, the code checks to see if Joomla is logged in and SMF is not, and if it isnt, then do the login?

I confess other than looking at SSI.php I havent done anything else, but even doing the opposite would work? (auto log in Joomla if SMF is logged in?)

As a code concept though, both Joomla and SMF need to name their variables better, both internally and in CSS: prefixing a css_class with J15 or SMF1 adds little overhead and would eliminate all the bs-clashes thousands of developers discovering that little rut in the road have encountered over the years.

The code where Global variables are overwritten has to go as well.


SMF was designed to be stand alone, so I guess Joomla should have named it's CSS better -hopefully they change that in J1.5

You have to give the Joomla guys some slack though. Much of all this effort is due to them wanting to FINALLY come out of the 'shadow of Mambo' and it's legacy code and really 'be their own person'. It's just growing pains really, and with a finite amount of part-time developers and an infinite amount of issues, its no wonder that there is a bit more of short tempered or rather, not as well thought out responses as everyone would like.

I believe extensive code changes WILL come out of SMF -  SMF NEEDS to be more component based and not rely so much on being THE app. The web is all about assembly and mashups not code edifices.

While some may disagree,the post/respond model only goes so far, a site needs more than a forum.

That is why I think the key development area for SMF will be the SSI.php/API where people can draw on the SMF code base and design infrastructure WITHOUT EVEN HAVING A "RECOGNISABLE" FORUM.

[Orstio]

but isnt there a SSI_Login/Logout function in SMF (ssi_php) so that  all you need to do on the Joomla side for minimal functionality: ie. Single Login is to just log in via Joomla, then, when the page refreshes, the code checks to see if Joomla is logged in and SMF is not, and if it isnt, then do the login?

I don't think you would ever want to do it this way.  It would work, no doubt, but think about the fact that you would be checking for a login in Joomla, and then checking for the corresponding login for SMF with each and every click of each and every guest (You would probably also want to check to see if a SMF user that was logged in was also logged into Joomla, yes?).  That adds up to 3 queries minimum, possibly 6 if you actually want to migrate a user that exists in one but not the other, and up to 12 if you actually want to update member data etc.  As I said before, this would seriously limit scalability;  A forum of this size would never be able to handle it:

http://www.40konline.com/mos/index.php?option=com_smf&Itemid=861

That is the reason the bridge only performs those queries on events like logging in and registering, instead of on each and every click.

As a code concept though, both Joomla and SMF need to name their variables better, both internally and in CSS: prefixing a css_class with J15 or SMF1 adds little overhead and would eliminate all the bs-clashes thousands of developers discovering that little rut in the road have encountered over the years.

I think standardizing of CSS is always going to be an issue, regardless.  Most templates/themes are made by third parties, have their own CSS, and there really aren't any naming conventions or guidelines. 

You have to give the Joomla guys some slack though. Much of all this effort is due to them wanting to FINALLY come out of the 'shadow of Mambo' and it's legacy code and really 'be their own person'. It's just growing pains really, and with a finite amount of part-time developers and an infinite amount of issues, its no wonder that there is a bit more of short tempered or rather, not as well thought out responses as everyone would like.

I don't think anyone needs to be blamed for the situation.  Where I work, when things are going terribly wrong, we have an engineer who says "OK, this whole thing is my fault.  Now that's out of the way, where do we go from here?"  As I said before, the announcement was intended to give people time to weigh their options and decide what they wanted to do for their own sites.  It was not intended to spur a whole lot of debate over whom to blame, political maneuvres like petitions and attempts at persuasion or convincing, nor a lot of conversation around virtual solutions on which I have already tried in practice many different variations over the past nine months of attempting.  I know of seven different methods of bridging SMF to other applications without modifying source files, and trust me when I say I've tried all of them, and many variations on each, and I've come up with nothing satisfactory.  I'm starting to think it would have been less hassle to wait until Joomla 1.5 was released, and just not make a bridge, and not bother answering questions about it, and letting people scramble at the last minute.

I believe extensive code changes WILL come out of SMF -  SMF NEEDS to be more component based and not rely so much on being THE app. The web is all about assembly and mashups not code edifices.

The overwhelming majority of users who use SMF exclusively as a stand alone product would disagree with that statement.  People who use SMF as a part of a CMS are a very small minority.   Changing SMF to run mainly as a "component" (plugin?, module?, extension?, fusion?, depending on which CMS we're referring) of any particular CMS would limit its distribution, IMO.

[AmyStephen]

I'm starting to think it would have been less hassle to wait until Joomla 1.5 was released, and just not make a bridge, and not bother answering questions about it, and letting people scramble at the last minute.

Thanks for not doing that, and yes, it probably would have been easier. Orstio - Thanks. We'll get where we are going. It'll all make sense then. I appreciate what you have had to say. Amy

[elfishtroll]

In the oft contentious field of software development, any path not taken would've been the "best" one!
It's all about trade-offs.
Reading the (as yet uncensored ) threads at Joomla.org, to me it does seem, SMF got treated with a little less than the due regard one would expect... (3 months for a reply coming out of Joomla???)

In hindsight it's perfectly understandable. J-specific extensions like Community Builder,VirtuMart and Facile Forms strengthen the "Joomla Brand" -people will switch to Joomla (and follow it) BECAUSE of those applications; hence the alacrity when Facile Forms developer Peter Koch screams he cant get FF to work in 1.5! Everyone "drops everything" to prove it isnt so, and that the problems are not insurmountable.
Also, many of those Joomla Flagship "killer/must have" app devs  are Joomla devs anyway.. you can rest assured that an upgrade path for Joomla isnt going to invalidate their entire codebase overnight!
(Note, to paraphrase AmyStephens: this isnt indicative necessarily of "evil intent", but dont be surprised when a mother rushes into a burning Day Care Center; she invariably returns with HER child!
People tend to prioritize THEIR interests higher,tis  only human nature:P
)
With SMF on the other hand, Joomla isn't really needed for it to work. Code wise, SMF is some years ahead of Joomla and its login (encrypting BEFORE passing passwords across the net) and ACL system. Bridging with Joomla actually WEAKENS SMF security more than anything as the bridge seems to fall back to the weaker MD5 code... Joomla cant take anything useful from SMF anyway, as SMF is NOT opensource but  proprietary free, so f*ck SMF, 'they arent  really "one of us" anyway' (actual quote)

anyway, (politics aside) to the REAL topic..

I was thinking that loading SSI.php (which I would be doing ANYWAY to expose the functionality that it offers) would give me the SMF login status via $context['user']['is_logged'] and all I have to do is compare if there is the corresponding $my-> information re: the Joomla side.

I confess to not looking at scalability issues regarding that, (or even if I could/would since I would be pulling SSI.php regardless) ... thats what I've been doing thus far successfully anyway.

I dont do any login/account bridging. SMF creates all user accounts, period, Joomla logins get converted en masse, one-time, NOT on the fly.

The overwhelming majority of users who use SMF exclusively as a stand alone product would disagree with that statement.  People who use SMF as a part of a CMS are a very small minority.   Changing SMF to run mainly as a "component" (plugin?, module?, extension?, fusion?, depending on which CMS we're referring) of any particular CMS would limit its distribution, IMO.

Making SMF more component-able (new phrase, coined by me, feel free to use ) I think that would actually make SMF *MORE* available not less!

It could be a simple matter of extending SSI.php more, for instance ADD COMMENT, FEEDBACK could all be implemented with a call to SSI.php w/o having a 'recognizable forum interface'. (not that THAT is a bad thing, but just imagine: SMF within FLASH or Java?)
It would not be cannibalizing the existing user base, it would be adding!

You have a small blog or one page website: You can have a FULL ROBUST Discussion area with file uploads, quotes and attachments and all of the administrative control currently) -without having a "forum" per se?
SMF would STILL exist as a stand-alone application though... the suggestions are not intended to replace the standalone functionality but to extend it.


What say you Ortiso?

P.s. I'm also interested in any 'cut and paste' comments Amy may have to add as well...

[Orstio]

It could be a simple matter of extending SSI.php more, for instance ADD COMMENT, FEEDBACK could all be implemented with a call to SSI.php w/o having a 'recognizable forum interface'. (not that THAT is a bad thing, but just imagine: SMF within FLASH or Java?)
It would not be cannibalizing the existing user base, it would be adding!

Actually, we've been discussing ways of extending SSI more.  There are a few ideas on the table, and extensibility of SSI is a major point.

If you have ideas on additional SSI functions that would be useful, please feel free to start a topic about it in the Feature Requests board.  You might not get a response, but rest assured, the devs all look in there for ideas to implement.

SSI can do some nifty, and even some powerful things, but I haven't really seen a full-on SSI-based site that actually uses what is currently available to its full potential.  People usually just use the built-in functions, which are really just a small part of what SSI can really do.  Take a look at the code from my "Related Topics" module for the bridge for an example of something a little more advanced that is completely based on SSI.  While SSI is great, it will always have its limits, however.  Some of the earlier bridges were SSI-based, and I ran into certain limitations with them that I could overcome by including SMF directly into an output buffer.  One example of a limitation of SSI is the fact that sub-board themes are not respected (with good reason).  It just wasn't quite enough for what bridge users needed.

That isn't to say that aren't users who wouldn't be perfectly happy with just a bit of SSI.

[joseph21]

I think my head hurts now..  Joomla is nice, SMF is nice. Both are nice. If one is out, then there's no point to have a good CMS site.. How is it not going to be compatible the tables and database transferred to Mambo from Joomla?

[xtremecruiser]

There is always Mambo, Tiny Portal, MKPortal, etc
Too bad really, I was begining to like Joomla

[joomla]

I suggest you read the entire thread before reaching erroneous conclusions.

[elfishtroll]

I suggest you read the entire thread before reaching erroneous conclusions.

Which conclusion is erroneous?

that there are Mambo, TP etc as alternatives?


or that he always liked Joomla?

Maybe one should read the whole post before reaching erroneous conclusions?

sounds like words to live by!















(lmao)

[joomla]

No, in case anyone missed it:

There will be a bridge for Joomla 1.5




All this paranoia and hype is unnecessary.

[BarryBarry]

Maybe close this thread, with your last message, to prevent miscommunication?

No, in case anyone missed it:

There will be a bridge for Joomla 1.5




All this paranoia and hype is unnecessary.

[elfishtroll]

No, in case anyone missed it:

There will be a bridge for Joomla 1.5




All this paranoia and hype is unnecessary.

While the 'title' of the thread is perhaps unfortunate, it is the height of hyperbole  (and some may even say rudeness) for you to demean the contents of it as 'PARANOIA' and 'HYPE'.

I agree that there WILL be  bridges of some sort emerging between Joomla 1.5 and SMF, as "market forces" demand.  The fact that NEITHER will appear to have the attentions of the core developers of either software would, past history being the guide, have the solutions (initially at least) being unfortunate kludges with significant manual editing to both code bases - something which we have thus far been spoiled to not have to do for the most part.

The contributions, questions and queries raised have for the most part been well reasoned and the "responses from the elders" have been remarkably well tempered, measured and helpful! ( with the obvious exceptions of course  ^ 

However, if you really believe the contents are just inflammatory hype, paranoia etc, Joomla, then you should probably delete this thread. (for the good of the people)

[AmyStephen]

The developers are continuing to work on the SMF to Joomla! v 1.5 bridge. Let's have faith in our community and show support for Orstio and the Joomla! developers.