These files are not found.

When is the next release scheduled?

Any updates from Enfold support? Seems like the most logical response to this issue.

Ha, their support structure is extremely poor. I inherited this theme for a site I manage, but I would have never used it.

I think wp_remote_get() is failing when the site has a self-signed certificate.

That’s my case exactly as well. I’ve since replaced that function with the native PHP file_get_contents() function in my code with some affordances for ssl/tls scenarios specific to my case and stored it as a recurring patch job in my git repo.

An entry in the Error log as to what is going on would be helpful.

Amongst SO MANY OTHER THINGS.

• This reply was modified 5 years, 5 months ago by Michael.

Well I’ve been looking at the theme code and I am seeing a variable naming conflict and conditional argument that should be refactored here as it is confusing, superfluous and doesn’t really handle the reasons for why the outcome wouldn’t occur in any sort of graceful manner except for failing altogether, especially if we’re going all the way to provide merging and compressing in the first place.

In the following file (/wp-content/themes/enfold/config-templatebuilder/avia-template-builder/php/asset-manager.class.php:416) I see this block of code:

//create a new file if we got any content
			if(trim($content) != "")
			{
				$file_path		= trailingslashit($stylesheet_dir).$data['hash'].".".$file_type;
				$file_created 	= avia_backend_create_file($file_path, $content);
				
				//double check if the file can be accessed
				if(is_readable($file_path))
				{
					$handle = fopen($file_path, "r");
					$filecontent = fread($handle, filesize($file_path));
					fclose( $handle );
					
					$file 		= $this->get_file_url($data, $file_type);
					$request 	= wp_remote_get($file);
					
					$file_created = false;
					if( ( ! $request instanceof WP_Error ) && is_array( $request ) && isset( $request['body'] ) )
					{
						$request['body'] = trim($request['body']);
						$filecontent = trim($filecontent);
					
						//if the content does not match the file is not accessible
						if($filecontent == $request['body'])
						{
							$file_created = true;
						}
					}
				}
			}
			
			//file creation failed
			if(!$file_created) return false;

If we look at lines 420, we have the variable $file_created, which should essentially always return true. Yet we later on line 432 re-assign the same variable $file_created to false, basically overriding the truthful result of the previous $file_created boolean state anyhow, regardless of it being true….???? That is a problem.

I also have to ask, why in lines 424 to 444 do we even bother checking to see if the file can be accessed by comparing the local PHP access to the a HTTP GET response??!? If the code successfully generated the file in the earlier step, then the file should be there. It is not the theme’s responsibility to determine HTTP response issues, but most likely a larger problem with the server or redirections, which this entire theme code block attempts to sloppily circumvent, but fails miserably when the problem arises regardless.

At the minimum, barring all of the other code issues, I would change the code to the following:

//create a new file if we got any content
			if(trim($content) != "")
			{
				$file_path		= trailingslashit($stylesheet_dir).$data['hash'].".".$file_type;
				$file_created 	= avia_backend_create_file($file_path, $content);
				
				//double check if the file can be accessed
				if(is_readable($file_path))
				{
					$handle = fopen($file_path, "r");
					$filecontent = fread($handle, filesize($file_path));
					fclose( $handle );
					
					$file 		= $this->get_file_url($data, $file_type);
					$request 	= wp_remote_get($file);
					
					// don't overwrite the above assignment of the $file_created variable, and remove this assignment: $file_created = false;
					if( ( ! $request instanceof WP_Error ) && is_array( $request ) && isset( $request['body'] ) )
					{
						$request['body'] = trim($request['body']);
						$filecontent = trim($filecontent);
					
						// if the content does not match, the file is not accessible
						if($filecontent != $request['body']) // if the file content DOES NOT equal the request body, then....
						{
							$file_created = false; // change from true to false
						}
					}
				}
			}
			
			//file creation failed, exit out of function
			if(!$file_created) return false;

• This reply was modified 5 years, 7 months ago by Michael.

Unfortunately, we’re going to have to work interactively over some sort of chat session as I cannot provide you with access to our public website due to our corporate privacy policies.

Please set up a time that works for you that I can coordinate chat via something like Discord or Skype.

I already said what I did, but here is the entire code block:

if(!function_exists('avia_backend_merge_colors'))
{
	/**
	 *  merges to colors
	 *  @param string $color1 hex color code
	 *  @param string $color2 hex color code
	 *  @return new color
	 */
	function avia_backend_merge_colors($color1, $color2)
	{
		if(empty($color1)) return $color2;
		if(empty($color2)) return $color1;

		$prepend = array("", "");
		$colors  = array(avia_backend_hex_to_rgb_array($color1), avia_backend_hex_to_rgb_array($color2));

		$final = array();
		foreach($colors[0] as $key => $color)
		{
			if (is_numeric($colors[0][$key]) && is_numeric($colors[1][$key])) {
				$final[$key] = (int) ceil(($colors[0][$key] + $colors[1][$key]) / 2);
			}
			
		}

		return avia_backend_get_hex_from_rgb($final[0], $final[1], $final[2]);

	}
}

• This reply was modified 5 years, 7 months ago by Michael.

So it was my own dang fault. Totally missed that. Thanks for the assistance.

Ok, so I got what you are saying here and just used the don’t display footer option and the hide header showing option. Problem here is that now there is a big white space on the mobile device. Can you assist?

Wasn’t even thinking about that. We will go in and change all the hard links to the new location. Thank you.