I’ve been maintaining a website built with Sparkle for about 5 years now. Last month I started using the SEO wizard (probably should have all along) but after noticing a ton of notifications I stopped. This is important because I didn’t run an update to the website after that and only went in today to do it again.
The problem is with the whole website, but this page in particular is a good example of what’s happening. The entire leadership team listed here changed but it’s still showing last year’s team and dates. MAISA Social Studies
So far I’ve tried multiple uploads and finally ended up deleting every last file on the server that Sparkle put there and re-uploading - it uploaded the old site.
Seeing a few related but not perfect match posts, I went to my tech folks since my school district hosts the website to see if they’d done any changes on their end. They haven’t really. Does anyone have any idea what could be causing this and what could we do to fix it?
The issue might be coming from the server cache, which is keeping an earlier version of the website. The fact that, even after deleting all the files and re-uploading the site, the previous version still appears suggests that a cached version is being served to visitors. You should try clearing the cache or ask the technicians to do it.
Thank you - I have made it home to my home laptop, downloaded the website file from my iCloud account and am now syncing it again - to it’s credit, it’s taking a long time which may be a good sign (my home internet is actually faster than my work internet) - if this doesn’t work I’ll point that out and keep investigating. They were definitely as puzzled as I was when I went in to see them
Can I suggest you publish first to disk and check that the output files display correctly in a browser. If all are ok, try using an FTP application to connect to the server and check that you are overwriting the old files in the correct location. Also check if you have two versions of the site, one in the public folder, and maybe one in a folder named www. I notice that your link goes to a site with the www.prefix, - not http or https. I’ve also noticed that the domain is showing as unsecured, meaning the one displaying doesn’t have an SSL certificate. I changed your URL to include the https:// prefix and it shows the same page, but it is now showing it’s a secure website. My feeling is that you may be uploading to the wrong section of the site. You maybe need to clarify where exactly the files need to uploaded,
If the issue is really coming from the server cache, re-uploading the site again unfortunately won’t change much. What you could do, once the upload is complete, is download one of the modified pages directly from your server and check the text in the source code. This will allow you to verify if the new version of the site has indeed been uploaded to the server. To download a page, you can use software like FileZilla, for example.
Tech department is going to check the server cache - I was returning here to ask the very suggestion that was above, is there a way for me to export the website to disc? That would help me narrow down for certain that it is in fact a server issue. Unfortunately, I had to leave my house to get to another appointment, and it was still uploading when I left I’ll be back in a few hours. All these Suggestions are fantastic and appreciated.
The issue you’re seeing with the domain defaulting to an insecure “www” version may be due to a missing or misconfigured SSL certificate for the “www” subdomain. While the non-www version (i.e., https://misocialstudies.org) works securely with HTTPS, the “www” version (http://www.misocialstudies.org) does not appear to redirect to HTTPS, causing the browser to flag it as insecure.
The second issue, where the old version of the page is still being served, is likely due to caching. This can happen at different levels, such as browser caching, server-side caching, or even CDN (Content Delivery Network) caching. Clearing the cache at all levels or setting up proper cache-control headers can resolve this.
I recommend:
Ensuring both the “www” and non-www versions of the site have valid SSL certificates and redirect correctly to HTTPS.
Clearing the cache on your server or CDN, and adding cache-control headers to make sure the updated page is served to visitors.
You can also verify these changes by manually clearing your browser cache or using tools like Chrome’s Developer Tools to see which version is being served.
To download your files from the server and verify that the updated version of the site has been uploaded, you can use software like FileZilla to retrieve one or more pages directly from the server. Then, you can open these files locally (for example maisa-social-studies.html) and check the source code to see if they contain the modified text.
Although this isn’t directly related to their issue, I agree with you that setting up a redirection to HTTPS is important. However, I don’t see why you say the ‘www’ subdomain is the problem. Connecting to the site via HTTP://misocialstudies.org/ without ‘www’ also doesn’t redirect to a secure connection.
Without correctly configured redirects on the server, you have to be very specific in what you enter into the browser address bar. You must specify the https:// prefix. This is what happens when you do.
This is what makes me think that the issue may have something to do with server redirects. Essentially, just putting a domain name into a browser should automatically point to the https version of the website, regardless of whether you add a www prefix, or don’t add a prefix at all. The fact that you are seeing secured and insecure versions of the site based on the prefix, or lack of a prefix suggest that there may be different versions of the site in different folders or subdomains. So you should get the server configured correctly, and then upload the site again. It should go into the public folder on the server, and everything should point to that version. This should solve the problem - or at least resolve the confusion.
Seriously thanks for all the advice. I’m home now and when I pull the file with today’s datestamp and time under last updated, I get this - which is correct (minus the images that aren’t loading because obviously I only opened the HTML file locally and didn’t download any of the images)
So - I’m guessing we’re back to server side issue and I have let my tech team know 1) That it’s probably something on our end and to look at the certificates, and 2) not to worry about it until Monday because I’m in no hurry to be the primary contact for this particular network and until the page updates, poor Molly is still technically in charge
Thank you all. If any other thoughts occur to you that might help us navigate this I’ll welcome them - otherwise have a great weekend!
The caching issue has nothing to do with the certificate. Additionally, the certificate is valid and present, the only problem is that HTTP isn’t automatically redirecting to HTTPS. To fix this, it’s fairly simple. You’ll need to create or modify a file named .htaccess:
Access your server and go to the public_html directory (or the root folder where your site files like index.html are located) and look for a file named .htaccess.
If the file already exists, download it to your computer for editing, but be careful not to delete anything that’s already in it. If the file doesn’t exist, you can create one directly on your computer. Simply open a text editor (like TextEdit), then save the file under the name .htaccess (without any extension).
Open the .htaccess file with your text editor, then add or modify the content as follows:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Save and upload the file: Once the modifications are done, save the file and upload it to the public_html directory (or the root) of your server via FTP.
This will automatically redirect visitors from HTTP to HTTPS for all pages of the site.
It’s also possible to configure caching management through the .htaccess file to instruct browsers or servers to check for page updates. But it might be better to consult the technicians for this.
So - after trying these thigns and still not getting anywhere, I remembered I backed up back in July before a substantial update. When I pulled that backup and uploaded all changes took immediately and I’m now working on porting all the updated content (but not the pages just in case) over from the newest version into that backup. When done I’ll back this up for September since I did quite a few changes between the two copies of the file.
Weird but fixed. It’s something I must have done to the Sparkle File between the updates I loaded in mid-August and last week when I discovered the issue.
