Issues with Style and Script Merging

File permissions are:

rwx rwx r-x (775)
user/group: apache apache

What’s interesting is that the files end up getting generated.

• 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.

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.

@ismael to answer some of your questions:

We are hosting our website on our own internal hardware with VMs running CentOS. We have a Kemp load-balancer between the server and the public. The CentOS server has self-signed certificates for SSL/TLS on it, and the Kemp load-balancer has the domain name certs that get replaced in the exchange passthrough.
This is likely why it the theme fails on its verification of files using wp_remote_get() because it is accessing/referencing itself publicly through our local NAT and not hair-pinning out on the internet and then coming through the Kemp to get the certificates.

Your resource regarding this: https://wordpress.stackexchange.com/questions/167898/is-it-safe-to-use-sslverify-true-for-with-wp-remote-get-wp-remote-post#answer-167910 states the following, which I think pretty much sums up what your team should do:

If this is a publicly distributed plugin, then you might want to attach that to a simple option that the user can turn on or off. You could as well try the verified request first and if not (and if the user has opted in for a unsigned request), then switch to a potentially unsafe request.

Your team should add a switch to the settings of the theme, to turn off verifying of the SSL certificates, should we have a setup where load-balancers exist or complicated SSL certificate setups cause these sorts of errors.

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

When is the next release scheduled?

If it’s going to take longer than a month, please let me know, or share the code blocks with the changes for this.

These files are not found.