Skip to content

Conversation

@Rupurudu
Copy link
Contributor

@Rupurudu Rupurudu commented Jun 2, 2025

Early SMF initialization and Ajax Login

  • Moved the SMF initialization from template class to the skin class. This allows us to use SMF's globals early. This is needed for setting SMF's headers.
  • Added SMF's headers. This is needed for JS.
  • Added the missing reqOverlayDiv function for ajax login. smfCurve2TemplateCustom template is already correcly set up to use it. Ajax login works now.
  • Removed the now obsolete fixes from popup functions, since loading SMF's globals fixes them.
  • Added a section to README.md about how to properly configure your forum to avoid CORS errors.
  • Fixed incorrect viewport setting. (copied from the curve2 theme)
  • Added missing theme color. (copied from the curve2 theme)

@Rupurudu
Copy link
Contributor Author

Rupurudu commented Jun 2, 2025

@jdarwood007 I made this change because I wanted to use SMF's globals in the meta tags and need to initialize SMF early for that.. But maybe the example usage I added may not be desireable for everyone. I can remove it if needed.

@Rupurudu Rupurudu force-pushed the early_smf_init branch 2 times, most recently from f88093b to 2975225 Compare June 2, 2025 13:18
@Rupurudu
Copy link
Contributor Author

Rupurudu commented Jun 2, 2025

I removed the previous example and added default JS variables for SMF. This plus the reqOverlayDiv enables ajax style login on smfCurve2TemplateCustom template.

@jdarwood007
Copy link
Member

An issue I see so far is that you changed the AJAX loading to use SMF's theme URL, which is only present when loaded with SSI. If SSI is off, that won't set.

@Rupurudu
Copy link
Contributor Author

Rupurudu commented Jun 6, 2025

An issue I see so far is that you changed the AJAX loading to use SMF's theme URL, which is only present when loaded with SSI. If SSI is off, that won't set.

This is kind of the point. The reqOverlayDiv function is essentially a copy-paste from SMF. While I could easily fix the function by including the loading gif into the mediawiki theme, I chose to load SMF's globals. This way we can use more of the SMF's scripts as-is, without modifications, which makes the development easier.

@Rupurudu Rupurudu force-pushed the early_smf_init branch 2 times, most recently from dff53f6 to 5f7d1ec Compare June 7, 2025 00:00
* Moved the SMF initialization from template class to the skin class. This allows us to use SMF's globals early. This is needed for setting SMF's headers.
* Added SMF's headers. This is needed for JS.
* Added the missing `reqOverlayDiv` function for ajax login. smfCurve2TemplateCustom template is already correcly set up to use it. Ajax login works now.
* Removed the now obsolete fixes from popup functions, since loading SMF's globals fixes them.
* Added a section to `README.md` about how to properly configure your forum to avoid CORS errors.
* Fixed incorrect viewport setting. (copied from the curve2 theme)
* Added missing theme color. (copied from the curve2 theme)

Signed-off-by: Mustafa Can Elmacı <[email protected]>
@Rupurudu Rupurudu changed the title Early SMF initialization Early SMF initialization and Ajax Login. Jun 7, 2025
@Rupurudu Rupurudu changed the title Early SMF initialization and Ajax Login. Early SMF initialization and Ajax Login Jun 7, 2025
@Rupurudu
Copy link
Contributor Author

Rupurudu commented Jun 7, 2025

  • Removed the now obsolete fixes from popup functions, since loading SMF's globals fixes them.
  • Added a section to README.md about how to properly configure your forum to avoid CORS errors.

@jdarwood007
Copy link
Member

This is kind of the point. The reqOverlayDiv function is essentially a copy-paste from SMF. While I could easily fix the function by including the loading gif into the mediawiki theme, I chose to load SMF's globals. This way we can use more of the SMF's scripts as-is, without modifications, which makes the development easier.

This is great in theory, but this theme is designed to operate under the assumption that SMF is not installed, i.e., it is standalone. If we wanted SMF fully, after loading SSI, we could have essentially called template_header/template_footer() and done some adjustments to capture the output for the logic that adds the scripts/css to inject them into SMF.

@Rupurudu
Copy link
Contributor Author

Rupurudu commented Jun 8, 2025

Well, I made the assumption that if an user enables the, smfMenu, smfUserMenu, (or smfNews #32) they have the SMF installed. reqOverlayDiv or smc_PopupMenu are not called (or even loaded, if the theme is not smfcurve2custom).

If the $wgsmfRoot is not set, and an user enables these options, fixing smf_images_url won't solve any problems since ajax request to the SMF would fail anyway.

I didn't see the need to seperate SMF integration, since smfMenu is part of the core theme already.

If we need to have SMF integration seperated from the core theme, I would suggest having a seperate skin/template instead, (let's for example call it smfCurve2SkinIntegration and smfCurve2TemplateIntegration). Then we would move anything that needs SMF out of the core theme into there.

smfcurve2custom should be for user modifications, not where we do our SMF integration.

So my proposal is:

  • smfcurve2 for Curve 2 without SMF installed.
  • smfcurve2integration (extends smfcurve2) for Curve 2 with SMF integrations.
  • smfcurve2custom for user modifications.

I can create smfcurve2integration and move SMF init and anything that needs SMF ( smfMenu, smfUserMenu, smfNews, etc.).

@jdarwood007
Copy link
Member

Creating the integration version would be acceptable. The idea for custom is to prepare some adjustments that allow for tweaking the provided template with changes. We use a modified version of the custom on our site to overload the changes yet again to integrate deeply into our site usage. But its otherwise the same as custom.

@Rupurudu
Copy link
Contributor Author

Rupurudu commented Aug 2, 2025

Creating the integration version would be acceptable. The idea for custom is to prepare some adjustments that allow for tweaking the provided template with changes. We use a modified version of the custom on our site to overload the changes yet again to integrate deeply into our site usage. But its otherwise the same as custom.

Sorry for the late reply. I completely forgot about this.

About the installation on wiki.simplemachines.org, I have found a number of differences unrelated to the customizations, even on the core theme.

For example if we compare the default curve2 theme on the simplemachines site to a fresh installation from this repo you might find that the quick search is missing:

(You can view the uncustomized version here: https://wiki.simplemachines.org/w/index.php?title=Main_Page&useskin=smfcurve2)

This is something I fixed myself (yet to be upstreamed).

There is also the case of icons, where this repo has missing most of the icons while it's visible on simplemachines website:

Again, this is something I fixed.

Also the Mobile menu fix #31 I upstreamed here is not yet installed to simplemachines.

So, my question is: How extensive are these modifications?

I'm asking this because looking at this repo's activity, and the number of fixes present on simplemachines site and not this repo, this theme is only used on simplemachines site.

Honestly, I don't want to waste my time upstreaming, if it ends up being not used.

Thanks for understanding. I've spent a lot of time making many changes and adding many new useful features like, forum news, forum logo (instead of showing mediawiki logo), forum slogan, collapseable sidebar and a completely redesigned usermenu that mimics SMF's usermenu for standalone and merged SMF/MediaWiki usermenu for use with smf-mw-auth. And it'll take me time and effort to beautify up my code, seperate them up to chunks, and open merge requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants