Resolved
Resolved in: WPML Multilingual CMS 3.9.4
Overview of the issue
If your web server is running on a Windows based machine, there is a limitation related to the maximum path length of 255 characters.
This is a known limitation of Windows that is related to the file systems (both Fat32 and NTFS are affected).
However, this limitation is reached in some cases because of some WordPress functions in our plugins for updating WPML from the back-end automatically.
You can read more and follow the issue at the WordPress trac https://core.trac.wordpress.org/ticket/34938.
Workaround
As a workaround, it is advised that you update the WPML plugins manually by FTP.
Otherwise, you can deactivate and delete the WPML plugins, then upload their up-to-date versions in Plugins->Add New.
Hy, I updated the plugin manually by FTP and through wpml control panel / Plugins / Add New but I’ve the same problem “Downloading is not possible. WordPress cannot create required folders because of the 256 characters limitation of the current Windows environment.”.
Sorry but I don’t understand this solution https://core.trac.wordpress.org/ticket/34938??!! I’m and IT servers, I’m not a programmer.
I do not know what else I can do.
This problem is happening because PHP cannot write correctly to directory with very long names on Windows servers. You can update manually. If there’s a way for you to move this installation to a path that’s shorter, automatic updates will work too.
So nothing changed in the windows environment but you claim this is a windows issue? I would have to say the problem isn’t related to the windows environment at all and is actually related to WPML’s recent plugin update including path names which are far too long. Blaming an environment which did not change isn’t a solution – you rolled out a crappy update and caused an issue.
Hello Jer,
As explained in the errata, this is due to the way WordPress creates the temporary file which, in Windows, causes the issue with the file name being too long.
This limitation in Windows file system is not new. In fact, it always existed.
The problem is in WordPress and is clearly marked as fixed on their side.
See https://core.trac.wordpress.org/ticket/34938#comment:9
This should solve the issue in most of the websites running under Windows.
However, if the temporary directory or your website already live in a long path (e.g. c:/some/very/long/path/iis/www/mysite.tld), the issue may still exists, as the concatenation of the files and directories created for WPML may end up by being longer than 255 characters (which, again, is not a new limitation).
We can’t solve this: it’s really a limitation in the operating system and, from our side, we can’t simply move all files into a single directory, as this would make our code unmaintainable, not to mention that Windows also has a limitation related to the number of files which can be stored in the same directory.
If you are already using WordPress 4.6 and the most recent version of WPML and you are still noticing the issue, I recommend you considering to move the website into a directory with less nesting levels and/or shorter names.
Even better, if this is an option, I would consider moving to a Linux based hosting.
If none of the options is possible, I’m afraid I can’t help any further.
Regards,
Andrea
My website directory is 9 characters long….that’s not very long. When I look at any of the WPML files they all start with at least 12 characters before we even get into the structure – add that to my 9 and we have 21 characters right there and almost 50 characters for a .CSS file….?
This is the only plugin I am having this issue with so I must be missing something….
This issue is party because of OS path size limitation but also because WordPress generates very long ID that is inserted in the path during file installation.
Is there a way to decrease the size of the ID ?
In my opinion, this is not possible.
WordPress does not allow to hook into that part of the code.
One workaround on the user end is to hook into wp_unique_filename (available as of WordPress 4.5.0), and to create a hash of the filename.
There is a small chance for collisions though, ie wp_tempnam() might be invoked more than once internally. One needs to be careful here, as wp_tempnam() has no safety measures implemented that would prevent infinite recursion!
add_filter(
'wp_unique_filename',
function ($filename, $ext, $dir) {
if ($dir === get_temp_dir()) {
return hash('sha256', $filename);
}
return $filename;
},
10, 3
);
For even shorter names one could use sha1, md5, or even crc32, which however in turn increases the chance for collisions.
Unfortunately code formatting is being lost in the comments, for something more readable: https://gist.github.com/anonymous/d6235efc3cea92e57cce6ae8b50b97bf.
Hello Oliver,
Thank you for the suggestion, I will inform our developers about this possibility.
Two years to solve a Plugging issue (not a windows problem)
Regrettable
any news on solving this issue? its getting massive annoying……
We still don’t have progress on this issue.
As it is indicated – it actually depends on a change in WordPress itself.
Our developers are continuing to work on finding an alternative way of patching this.
However, for now, there is no code that is stable enough for testing.
I have just fixed the issue where Windows would not allow creating path-length of greater than 256 characters, but unfortunately the plugin still gives the message that it could not update.
I checked the source-code of the function that does this check, and it doesn’t actually check if windows would be able to create the temp-folder, but it just does the math if it would be too long or not.
I fixed this temporarily by increasing the $windows_max_path_length variable value (in Installer_Dependencies class in the function ‘is_win_paths_exception’), to make sure it returns true, but obviously this is not a viable solution in the long term.
After making the change, the update ran correctly, without any issues (as expected)
Is it possible to either wrap the function or one of the variables that is used to make the calculation within a WordPress filter? This way it can be filtered manually to make sure the updates can be run, even on a (correctly configured) Windows installation.
Hopefully this helps other users/development to update the core-code.
Rowan
Hello.
I am not sure how you fixed that problem with the path length as even if you reduce the path of the folder where your site is located – you still might be affected.
The function that checks the path length is in place for a very specific reason.
If you bypass this function is it possible that you receive a partial install of one of our plugins and that could lead to a fatal error and broken site. Obviously, I would not recommend doing that.
I fixed the issue in Windows itself (so that it can create paths longer than 256 characters), but with that function still active, it would not allow me to update automatically.
With the suggested fix, you’d be able to update automatically if your Windows environment is set up correctly.
Hope this helps
Rowan
Do you have any technical docs on how this can be fixed in Windows itself?
We can review and test if it works and include them in our documentation – so more people could benefit from them.
It’s not ‘technical documentation’ but I followed https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/
by editing the following Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled
Thank you for the details.
I will consult with my superiors and discuss the possibility of adding this as an exception case-workaround for this issue.
Was curious if this was worked on at all? We are hitting into this as well.
thanks
Hello!
Of course it is being worked on this.
As far as I am aware, we are going to fix this in the next major WPML release – provided that the fix works and that it passes QA.
The issue should now be resolved in our current release of WPML 3.9.4