PHPSESSID in link path css/js, default theme

[Butiks]

Hello.

On my first visit, the styles (css and js) are not displayed.
It looks like a forum page with unformatted title and text blocks.

After reloading the page, everything is immediately displayed well.

When I go to the forum for the first time "in incognito mode" in the browser, you can see PHPSESSID everywhere in the source code (Ctrl+U).
Everywhere in the links of topics and categories and profiles and in the paths of css and javascript styles.

How to remove `PHPSESSID=...` from css/js paths?

I tried to specify the paths for css in ../index.template.php, but in the end it was embedded in the path too
Example:

Code Select Expand

<script src="https://forum.com/?PHPSESSID=aaae5d088b01a7222c8bf2b28f654612&amp;Themes/default/scripts/script.js?smf213_1711726823"></script>
...
<link rel="stylesheet" href="https://forum.com/?PHPSESSID=aaae5d088b01a7222c8bf2b28f654612&amp;Themes/default/css/index.css?_v=1">
...
SMF: 2.1.3
Mods:
Optimus 2.11
Hide Content 2.2.1
Quick Spoiler 1.5.2
Avatars Display Integration 1.5.4
Similar Topics 1.2.3
SMF 2.1.4 Update 1.0
Simple Colorizer 1.4

[Kindred]

1- don't do that. Take thise edits out.

2- use htaccess to force the visitor to use https and non-www url.

[Butiks]

The forum works without `www` in links, and via `HTTPS` (forced cloudflare)

All links have PHPSESSID and except this link

Code Select Expand

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>

[Aleksi "Lex" Kilpinen]

You should select ONE variation of urls, use it for everything, and redirect everyone directly to that on the server lever. Everything needs to be either http OR https, everything needs to be either without www OR with www, do not mix and match. You can check current paths and urls for SMF through repair_settings, and you can usually redirect users to your selected URL with htaccess. Do not tamper with the URL structures inside SMF code.

What is repair_settings.php?
Converting to https, step-by-step... (Includes redirection info)

[Butiks]

All this is interesting. Thank you.
Please note that what I am describing, the same thing happens here on the official SMF forum.

1. Open the forum in a browser in incognito mode.
2. Look at the source code of the page and see PHPSESSID in all links, including in the style paths and in the JavaScript paths.
3. Reload the f5 page, now look again at the page code and you will not find PHPSESSID.
4. After reloading the page, PHPSESSID is no longer there.


Sample

Code Select Expand

<title>PHPSESSID in link path css/js, default theme</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta property="og:site_name" content="Simple Machines Community Forum">
<meta property="og:title" content="PHPSESSID in link path css/js, default theme">
<meta property="og:url" content="https://www.simplemachines.org/community/index.php?PHPSESSID=322f764e82db58ee1b795a5991d11835&amp;topic=588707.0">
<meta property="og:description" content="PHPSESSID in link path css/js, default theme">
<meta name="description" content="PHPSESSID in link path css/js, default theme">
<meta name="theme-color" content="#557EA0">
<link rel="canonical" href="https://www.simplemachines.org/community/index.php?topic=588707.0">
<link rel="help" href="https://www.simplemachines.org/community/index.php?PHPSESSID=322f764e82db58ee1b795a5991d11835&amp;action=help">
<link rel="contents" href="https://www.simplemachines.org/community/index.php?PHPSESSID=322f764e82db58ee1b795a5991d11835&amp;">
<link rel="search" href="https://www.simplemachines.org/community/index.php?PHPSESSID=322f764e82db58ee1b795a5991d11835&amp;action=search">
<link rel="alternate" type="application/rss+xml" title="Simple Machines Community Forum - RSS" href="https://www.simplemachines.org/community/index.php?PHPSESSID=322f764e82db58ee1b795a5991d11835&amp;action=.xml;type=rss2;board=254">
<link rel="alternate" type="application/atom+xml" title="Simple Machines Community Forum - Atom" href="https://www.simplemachines.org/community/index.php?PHPSESSID=322f764e82db58ee1b795a5991d11835&amp;action=.xml;type=atom;board=254">
<link rel="index" href="https://www.simplemachines.org/community/index.php?PHPSESSID=322f764e82db58ee1b795a5991d11835&amp;board=254.0"><style>.vv_special { display:none; }</style>


[Aleksi "Lex" Kilpinen]

Yeah, but that is not an issue. Not seeing the page correctly is. You are concentrating on the wrong thing.
At least for me, this forum here functions correctly on the first load even with incognito -mode.

[Kindred]

Exactly as lex says. The php session info is not your problem

[Butiks]

Well let it work as intended by the developers.
But I need to connect the forum styles to a static link to indicate the path to the css and this path is not spoiled by the introduction of PHPSESSID.
Tell me how to do this?

[shawnb61]

PHPSESSID is put there by php itself, not by SMF.

The session must be kept somewhere.  SMF uses cookies. 

But...  For those brief moments before the cookie exists, php will use PHPSESSID. E.g., first visit, first interaction, no cookie yet.

Normally it's so short-lived, nobody even sees PHPSESSID in the url.

However...  If you disable cookies via going incognito, you are forcing your system to do so.

This behavior will be seen on any site that uses php.

But as noted earlier, this is not the cause of your css/js issue... (Or everybody would see the problem...)   When we see this, it is normally due to the reasons stated above - url discrepancies.

If only some people are seeing this issue, which appears to be the case, it's possible their browser has cached a funky url.  A redirect should address that. 

[Arantor]

PHPSESSID is put there by php itself, not by SMF.

ob_sessRewrite cares to suggest otherwise.

The specific issue is that the OP has modded QueryString.php to cut index.php from $scripturl so the SID injector doesn't exclude the theme URLs when it should otherwise do so. This has been an issue for over a decade and it's time the SID injector actually went.

It won't entirely solve some of the bots-making-mass-new-sessions drama but bots that make mass new sessions weren't bothering to pass along the SID anyway to try to not create new sessions (that's the point of it, keeping the SID in there even for bots that didn't bother to handle cookies, so as to try to keep the online log correct, valid solution in 2004, but... it's not 2004 any more)