Symlink Issues - __FILE__ vs. get_theme_root()

[Luehrsen]

Short Prefix: This is most likely just a development issue. Our development workflow is based around the theme sitting in a build process folder (build/trunk) in its own repository. To test the theme locally we create Symlinks between the WordPress Theme Folder and the trunk folder.

Actual Behavior:

• What is the issue? (*) The symlink logic doesn't see that it is sitting in a theme folder. Therefore the SDK ist unable to work for us locally, what makes development very hard. The main issue is at line 47 of the start.php file of the theme SDK.

As a reference, this is the output of the variables:

$file_path = "/Projekte/wp_development/themes/agncy/trunk/freemius/start.php";
$fs_root_path = "/Projekte/wp_development/themes/agncy/trunk/freemius";
$themes_directory = "/Projekte/htdocs/wpdemo/wp-content/themes";
$themes_directory_name = "themes";
$theme_candidate_basename = "trunk/freemius";

This all stems from the fact, that the FILE constant resolves symlinks. This in itself is not a problem, but the checks on Line 55 can't see that the SKD is indeed in a theme folder (just behind a symlink) and so the SDK doesn't work correctly.

• What is the expected behavior? I expect the SDK to compare paths in a way that pay respect to potential symlinks. Maybe offer an option or a development constant, that we can set in the wp-config.php to override the automatic pathfinding.

Versions: (*)

• Freemius SDK Version: 1.2.2.7
• WordPress Version: 4.8.1
• PHP Version: 7.1.0

Plugin / Theme: (*)

• Name: Agncy
• Slug: agncy
• Freemius ID: 1282

Additional Information:

• Browser Type: (*) Chrome
• Browser Version: (*) 60.0.3112.90
• OS: (*) MacOS X / Mamp

[vovafeldman]

@Luehrsen just to make sure I have all the data, is your symlink maps /Projekte/wp_development/themes/agncy/trunk/ to /Projekte/wp_development/themes/agncy/?

[Luehrsen]

No, the symlink goes into a completely different file tree.

/Projekte/wp_development/themes/agncy/trunk => /Projekte/htdocs/wpdemo/wp-content/themes/agncy/

We keep our theme separated from the Wordpress instance for easier development. That way we can test the theme with multiple Wordpress systems and remain in a continuous integration environment.

[vovafeldman]

It should work then. Let's schedule a quick TeamViewer session so I can do some vars inspection on right on your environment using a debugger.

[Luehrsen]

Can do. Feel free to add me on any IM or Facebook to coordinate that a bit better.

I'm sitting in GMT+2 (Munich), so for me anything in the afternoon this week should work.

[Luehrsen]

As a reference: With a standard drop-in installation, these are the errors I'm getting.

AFAIK most of these errors fall back to the fact that the script cannot see itself in the theme folder, therefore falls back to plugin mode and breaks.

[Luehrsen]

What put me on the right path was seeing the crooked enqueue path for the styles:

[vovafeldman]

Sent you a FB friend request.

[Luehrsen]

Started working on this again. Installed fresh code from the develop branch at commit bc2bcc809b949cc704fd9e49636f54c5161a1e3e.

This is the xdebug output:

[Luehrsen]

I have var dumped the result of 'get_module_type()' and my theme self identifies as plugin.

[Luehrsen]

The function ´get_caller_main_file_and_type´also has problems correctly identifying the theme.

[Luehrsen]

I have traced one of the issues down to this if statement, that (because of the symlink) doesnt return true when it should.

https://github.com/Freemius/wordpress-sdk/blob/1992b7ffd07d5a6c169a4fa587aa335a6ef78021/includes/class-freemius.php#L1004-L1008

[Luehrsen]

My current fix looks like this:

if ( $caller_file_path == fs_normalize_path( realpath( trailingslashit( get_stylesheet_directory() ) . basename( $caller_file_path ) ) ) ) {
         $module_type           = WP_FS__MODULE_TYPE_THEME;
         $caller_file_candidate = $caller_file_path;
         continue;
}

The assumption is: If we are talking about a theme and if the caller_file is function.php, it must be in the directory of the current active theme. So I map it like this, solve all symlinks with 'realpath' and we have a match.

Current issues could arise, if the sdk is called from a parent theme.

[Luehrsen]

Next symlink issue:

The function fs_asset_url can't construct a functioning URL, so i don't get assets. :D

[Luehrsen]

Just as a side note: A lot of these issues would resolve if you could provide URI and PATH to the SDK folder from the init function constructor.

[vovafeldman]

@Luehrsen for performance and many additional reasons, the SDK has a special mechanism to automatically identify and use the newest SDK in the website among all the plugins and themes. Also, currently, the constructor of each module is initiated prior to the settings configuration (something that we'll try to change in the future), and since we need the path during the constructor execution, adding the URI and/or PATH won't help.

[vovafeldman]

@Luehrsen is the last fs_asset_url() issue you mentioned happens in the latest SDK version?

[Luehrsen]

Yes, I am on the current master branch. (Tested 3 minutes ago)

[vovafeldman]

@Luehrsen can you kindly report if the issue happens with the latest develop branch? We made a bunch of improvements to symlinks and environment replications that should resolve this issue.

[Luehrsen]

@vovafeldman Downloaded 3 Minutes ago.

I am still getting malformed asset URLs and a new fatal error.

[victorholt]

Hey @vovafeldman I believe this might be related as I'm having a symlink issue as well. The following line:

https://github.com/Freemius/wordpress-sdk/blob/master/includes/class-freemius.php#L848

seems to be returning a non-symlink version of a site I'm working on. I'm using this plugin through the stop-user-enumeration plugin and I was wondering if there were any solutions for resolving this issue through a configuration setting?

[vovafeldman]

@Luehrsen please send us a link to the zip file of the theme and we'll test it on our end.

@victorholt did you try to use the develop branch?