Open xoich opened 3 years ago
Here are some ideas:
Plugin Name
header, and Version
is probably also required for the update checker to actually be useful.Does this only happen if you add a custom namespace to the update checker?
No.
Is the plugin file name correct? Ideally, it should be the full path to the plugin file, not a relative path.
I'm not entirely sure if that is what you are asking, but the plugin is in wp-content/plugins/my-plugin/my-plugin.php and I pass 'my-plugin' to buildUpdateChecker
Does the plugin file contain a valid plugin header? It must have at least a Plugin Name header, and Version is probably also required for the update checker to actually be useful.
yes
Is any part of the path a symbolic link? Those have caused problems in the past. I think I fixed some of the issues, but it's possible that I have missed something.
Yes, it's a bitnami installation and at least wp-content is a symbolic link.
I'm not entirely sure if that is what you are asking, but the plugin is in wp-content/plugins/my-plugin/my-plugin.php and I pass 'my-plugin' to buildUpdateChecker
Do you mean that you literally pass the string 'my-plugin' to buildUpdateChecker()
? Is that for the plugin path (second argument) or the slug (third argument)?
Yes, it's a bitnami installation and at least wp-content is a symbolic link.
It would make debugging easier if I could reproduce this issue locally. Are you using a prebuilt VM image or something else that that would be straightforward to set up? Can you share the update checker initialization code?
If that's not feasible, I would recommend to try debugging the buildUpdateChecker()
and isPluginFile()
method yourself. Specifically, it would be useful to know what the $fullPath
variable contains after it gets normalized, and which return
statement is executed in isPluginFile()
.