I’m not able to upload images, either as topper images or in the body of the posts.
I’m able to upload and see the topper image when I’m creating a post, but after saving the image doesn’t show up, just a blank field where it should be. When I go back into the post, the topper area is blank again.
As far as uploading into the body of a post, the markdown link is created, but nothing shows up on the live site.
I’m on PHP version 7.3.32 and I checked the General and Publishing settings in RW and the URLs are the same and correct. There are no slashes in the folder names either. I’m not sure how to check if the “Image Uploads folder is writable” as suggested in the documentation, but the images do show up in the “image-uploads” folder on the server so I assume…?
Provide us a copy of your project file please, along with a link to the live site.
Create a ZIP file containing your project file. This is the file you open in RapidWeaver to edit your site. After creating the ZIP file, upload it using a service like Dropbox, WeTransfer, Droplr, or a similar service to create download link for us. Past that download link in your reply.
Addendum – Is this happening on your live server or on your MAMP installation?
There should have been an image called “After the Fire cover art” on the latest post. I had also tried uploading a smaller image (1.2MB vs 4.3MB) but that didn’t change anything.
I ask because I just published your project here, and uploaded your photo you provided using the Editor. You can see the example post here: Dan Frechette & Laurel Thomsen - News
The only thing I did was to change the publishing location and general site URL to match my server.
Can you try something for me? Simplify the file’s name to something like after-the-fire.jpg and upload that as a test.
Additionally – are you exporting locally and uploading via FTP? If so, is there a specific reason you’re not using RW’s publishing feature? I only ask because I saw no server configured in your publishing setup.
Something to look at after you’ve got your image upload sorted out – The images you’re using throughout your site are quite large. Some are even up to 10mb. That’s no good, for you or your visitors.
Thank you! So yes, I tried uploading the smaller image, and even a smaller image that was only 140KB, but still no luck. I tried again with the simpler file name and that didn’t work either. Oddly, these new photos are also not uploading to the image-uploads file anymore either, but all the other behavior is the same. I made a test post on your server with that same image I’d provided you and it worked just fine, so am I right to assume it’s something about our servers that are different? Where would I start with figuring that out?
I haven’t set up the publishing in RW just because I was used to publishing through the FTP program Transmit with my pre-RW sites. If you think it could make a difference I’ll try publishing directly through RW.
Yes, my photos page is taking especially long to load… On average, what would be your recommendation for a photo size that’s clear across different devices?
in answer to your question about image sizes, I use images of 1720 px wide for hero banners and/or full screen banners (1720 px X 1300 px). See example of full screen here. I try to keep my images under 300k (for the largest sizes), preferably less.
Images in your website content are dependent on the container width. So if a container is 1440 px wide, there’s no need to make the images wider.
I compress images using Photoshop. Squash 3 seems to do a great job as well. Even in Preview you can do basic compression. The human eye is forgiving, so I dare compress up to 30% in some cases, but that depends on the detail in the image used.
It could be that something is misconfigured in your PHP installation or server, or that your host has some sort of restrictions in place.
I know you said you’re using PHP v7.3.32, which should be fine (in fact that is the same version running on the server where I published the test: CleanShot 2021-11-19 at 11.54.20). Here is a very simple PHP file you can temporarily put on your server to tell us more about your PHP install: phpinfo.php.zip - Droplr
Upload it to the main folder of the site your uploaded alongside your main home page index.php file and let us know when you’ve done it. That way I can get a screen grab of all of your settings.
Also, perhaps we can try this – either upgrade to v7.4.x or downgrade to v7.2.x and see if that makes a difference. In just doing so it will change the PHP installation and possibly right anything that might be wrong (depending on your host’s settings).
You mentioned previously that it was uploading to the image-uploads folder just not showing the image on the site, but now it is not even doing that. That seems pretty strange too if nothing with Alloy has changed between your two different attempts. I’d assume there’s nothing wrong with your folder permissions since your posts are being written OK, but can you let us know what the permissions for your image-uploads folder are?
Are you able to upload an image in the main body of the blog post OK? Does it show when published?
Lastly – If the above doesn’t sort things out, could you try uploading your image and when it fails to work, can you retrieve your PHP Error Log file and send it to me. This is stored in different locations depending on your host, so you might need to check their documentation to see where it is located if you don’t already know.
It shouldn’t make a difference. RapidWeaver should assign the same URLs whether published from RW or exported to a local folder and uploaded via your own FTP app.
I just exported your project to a local folder and uploaded it over the current test site on my server and all is working as it should.
To add to this discussion – I’d also highly recommend the site TinyPNG for compressing JPG and PNG images: https://tinypng.com
I know I’m asking a lot, but I’m just hoping I can get to the bottom of your problem…
Could you download your posts and image-uploads folders from your server via FTP? Then ZIP that up and share it with me privately. You can send a download link to the ZIP file here: adam at elixirgraphics dot com
I noticed you removed the image from the blog post on the live site, so before downloading things, can you try adding a topper image again, then download everything and make the ZIP file. Then if you want you can remove the topper image again.
Do this before you do any of the above stuff, if you haven’t already. That’ll let me see what it is generating in the posts, or not, on your server when you upload an image.
Ok, thanks! So meanwhile I tried uploading directly via RW and now there are a ton of images in the uploads folder that weren’t there when recently publishing through Transmit - all my previous attempts to upload images it seems! So that was interesting and I’m not sure what it means, but maybe something about my Transmit program is off?
Then I got in touch with my hosting (hostM) and they said the image folder “has an incorrect domain specified in the URL.” Sure enough, on line 245 of the “News” page index file it’s .com vs .ca showing up: “image”:{"@type":“ImageObject”,“url”:“https://www.danandlaurel.com/image-uploads/Dan%26Laurel_49_0.JPG”}
I’d noticed .com vs .ca under either the general or publishing settings in RW at some point as I was getting the site up, and changed it then, but somehow the images uploads folder wants to stick with .com I guess? Unfortunately I can only find this issue when searching the code in Firefox’s developer tools and not when I search the News index file that’s actually on the server, so I’m not sure how to actually edit it manually, though it seems like it should be really simple… But even then, would it just revert back to .com with site updates because something deeper in the system is telling it to do so? Wondering if I need to just scratch everything on the server side and re-upload the site now that all the URLs match and are correct or if there’s a quicker way to fix this that wouldn’t potentially delete the content already there?
The path for the uploaded image is created when you make the post. It reads the URL that is being provided by the site at that time, which it got from your project file’s settings. Even if you change the URLs, the existing post(s) will still have the old URLs. This is by design believe it or not. It would allow fallbacks in case you had to move the site but all of your images could still reside in the old location, among other things.
Not clear on where or what you’re seeing. Screenshots of this will help clear that up. Let us see what you’re seeing.
Your posts would still have the URLs pointing to the .com domain, because like I said those are written when your posts is created, and not when you publish the site. If you just delete everything then you’ll be deleting your posts, too.
You can edit the posts using any text editor and change the URLs within the Markdown files. That said, if you’ve corrected the URLs in RW you can do a Republish All Files using RW and it should set the Editor up to create the proper URLs when uploading images. After doing so you can log into the Editor, remove your image(s) from your post and then add them again using the Editor.
Ok, so I re-uploaded the site from RW and then I recreated the posts and now both the topper and main body type images seem to be uploading and showing up on the live site. Hopefully all is fixed now! I also checked and the URLs are correct in the code I can see online now, so that seems to have been the issue.
I thought I’d changed the URL discrepancy before making the posts, at least some of them, but maybe not. Live and learn. Thanks for your time and help on this!
Awesome! Good to hear it. Glad that in the end it wasn’t something major. Look forward to checking out the site when I sit down at the computer tomorrow morning!
Had a chance to sit in front of the computer this evening and just checked out the site again. Blog is looking great! Whole site is running faster now too with the smaller image sizes. Great work! If you ever have to give up the violin I think you’ve got a career in web design to fallback on.
