img src (unkown) in portfolio

• scolvin

  said

  Hello,

  We have a portfolio page setup on http://cms-builds.com/projects/. Featured images are displaying correctly within the project page, but the portfolio does not display the featured image (e.g. William Taylor Plaza, Old Trail Heights).

  Our host recently moved our site to AWS, so I believe it is likely related to some permissions within the theme, but I’m unsure what exactly.

  Thank you for your help.

• jeffw

  said

  I don’t think this is a theme issue, it is most likely, as you suggest, a server permissions issue.

  I think you would need to check the permissions on all the files and folders inside the ‘wp-content/uploads’ folder; that’s where WordPress stores all uploaded images and the thumbnail images it automatically creates from them.

  You can see on your example page that the thumbnails for older portfolio posts are displaying, so it’s maybe a permissions issue with just those recently uploaded images? A problem with the ’2019′ folder maybe? And/or the ’2019/01′ folder and/or files in that folder?

• scolvin

  said

  Thank you for your prompt reply, Jeff.

  I opened up the permissions on the uploads folder, but no luck. The images are uploading OK and display correctly within the portfolio item post. However, the featured image isn’t showing up on the portfolio page.

  Here is a copy of the source code of the element showing the missing image source.

  <a href="http://cms-builds.com/portfolio/william-taylor-plaza/" class="styled-image " title="Permalink to William Taylor Plaza" rel="group-932" data-lightbox="group-932"><img src="" width="600" height="722" alt="William Taylor Plaza"><div class="inner-overlay"><i><span class="entypo entypo-doc-text"></span></i></div></a><img src="" width="600" height="722" alt="William Taylor Plaza">

• jeffw

  said

  Okay, if you are sure that this is not a server permissions issue, let’s begin a standard troubleshooting procedure.

  I see you are using old versions of the theme and its associated plugins.

  Please update to the latest version of Vellum, currently v1.7.31 → http://para.llel.us/support/groups/vellum/forum/topic/latest-version-vellum/

  It’s very important that after you update the theme you also remember to update the required plugins. There are full instructions in the topic I have directed you towards above.

  If after updating the theme and its required plugins you still have this issue please let us know and we will work from there.

  I am not saying that updating the theme and its required plugins will necessarily fix this specific problem, but it is always best before you ask for support if you make sure the theme and its required plugins are updated to the latest versions currently available. Thanks.

• scolvin

  said

  Jeff,

  I’ve updated the site to the newest version and updated all plugins. The new VC is showing all of the shortcodes. Is there a way to strip those out without rebuilding the pages?

  Updated all plugins and deactivated all to test for conflict. Image error still exists.

• jeffw

  said

  With regard to the portfolio thumbnails not displaying, I’ve spoken with our development team about this and we are almost certain it is a permissions issue. The thumbnails for portfolio lists are generated by the theme, calling a WordPress specific function and storing the images inside a sub-folder structure like ‘yyyy/mm/cache’ in the ‘wp-content/uploads’ folder, and it appears that although this folder exists on your server, it is empty.

       → http://cms-builds.com/wp-content/uploads/2019/01/cache/

  Compare the above folder with this one created in February 2016 → http://cms-builds.com/wp-content/uploads/2016/02/cache/

  The fact that the ’2019/01/cache’ folder is empty means the server has the permissions applied in a way that somehow allowed the theme to generate the folder but not to save the resized images.

  To figure out how to configure your server permissions I think you may need to inspect your server error log to determine what kind of error it is throwing. (I think it is most likely to be an ownership issue rather than a direct read/write issue.)

  With regard to the other issue, i.e. the [vc_row] shortcodes displaying, this is a separate issue so if you can’t find a solution using the forum search please create a new topic for this separate issue and we’ll do our best to help.

  Thanks.

• scolvin

  said

  Jeff,

  From my host:

  “I’m stumped on this one. /wp-content/uploads/2019/01 and everything inside it are all set with wide-open permissions (777). That also includes the “cache” folder:
  /wp-content/uploads/2019/01/cache = 777

  Apache is the owner of all of that folder structure and files, but the owner wouldn’t matter at all if everything is 777.

  I’ve looked at the logs and haven’t found anything helpful.”

  Are there any other folders/file that we could try changing permissions on?

• jeffw

  said

  The fact that the ’2019/01/cache’ folder is empty means that at the time those featured images were set for those portfolio posts the server had the permissions applied in a way that somehow allowed the theme to generate the folder but not to save the resized images.

  Have you tried adding a new portfolio post after the permissions were changed?

  You can also try deleting the featured images for those four recent posts from your media library, and then uploading and setting those featured images again.

• jeffw

  said

  Apache is the owner of all of that folder structure and files, but the owner wouldn’t matter at all if everything is 777.

  We’ve seen situations in the past where folders in the ‘uploads’ folder were given apache/apache as group/owner by the server, and this was the cause of the problem. To give any files or folders apache/apache as group/owner is a server misconfiguration and it needs to be fixed. It means that WordPress cannot write to folders that it needs to write to in order to operate normally when installing themes and plugins. And it means that our theme also can’t write to folders it needs to write to.

  I’ve been down this road before with four web hosts, all of whom didn’t realise about the server misconfiguration until it was pointed out to them. Only one refused to correct the mistake, and that refusal cost them a customer. (And since then that web host has actually corrected the server misconfiguration.)

  If your web hosts seem reluctant to fix the misconfiguration, please point them to this article and ask them to read about why setting the group/owner to apache/apache is a bad idea. → https://codex.wordpress.org/Changing_File_Permissions#Permission_Scheme_for_WordPress

  One of our customers found that the problem was caused by running PHP as an Apache module. They switched to FastCGI and all the permissions and owner/group problems went away.

• scolvin

  said

  Jeff,

  Thanks for your help. The host resolved the issue. In case you’re interested for future cases:

  Stephen,

  Jeff discovered in the Apache log file the following:

  “PHP Fatal error: Uncaught Error: Call to undefined function imagecreatetruecolor()”

  That function is part of PHP’s GD Library – the library was not enabled on the 35.170.130.15 server, causing our problem – not permissions. We’ve enabled the library and all seems to be working fine now

• jeffw

  said

  Excellent! I’m glad your hosts managed to figure it out. There’s almost always a clue in the server error log.

  Thanks for following up.