This happen after package is uploaded and before we click install for the first time.
I'm not sure I would call it a bug as such.
file_exists cannot be performed due to open_basedir.
I'd say first try to fix the webserver, otherwise the package manager would not work and you may have problems?
Isn't open_basedir restriction is good for some security reasons or we should simply disable it because of this warning?
You should probably set it properly.
TBH I'm not a server-guy, so I can't give you much more details, maybe if
@Spuds passes by may have some suggestions (or revert what I said lol).
I finally concluded that this is a bug as I compare the code with 1.0.9. The default code in 1.1 Beta 3 is:
(!($package->isDir()) && file_exists($package->getPathname() . '/package-info.xml')
Where, based on 1.0.9, it is supposed to be:
(!($package->isDir() && file_exists($package->getPathname() . '/package-info.xml'))
It is the containing bracket, I think, which is incorrectly placed. I did the above changes and the error that is shown after addon's upload is now properly gone, instead of only being suppressed and instead of disabling the open_basedir restriction.
I hope this can be confirmed, as I myself am not so sure whether this the right fix.
I told you I'm not a server guy. :P
Just to repeat myself: I never said to disable it.
Not quite a "solution" but rather a workaround.
That one, instead, looks like a proper solution. ;)
I applied the fix proposed and did a bit more because that pattern is used elsewhere as well:
https://github.com/elkarte/Elkarte/commit/bb76c47a5326026603dd7a673c5fb531d0b91bbf
Glad you figured it out :D ... I was not sure why you were getting that error as the file appeared to be in the allowed open_basedir path.
IMO there is nothing wrong with using open_basedir, its something you should use if you have a multi user/site VPS, helps keep folks contained to where they (and scripts) can access.
Great. I have had a quick look but do not comprehend anything, yet. I am also not sure whether to test it since there is other file introduced.
By the way, from the quick look, is the backslash in this new PackagesFilterIterator class file proper because I haven't seen one like it before?
class PackagesFilterIterator extends \FilterIterator
yeh it's proper/valid syntax, but not required because it's all in the same namespace - none.
I added it just because I was thinking of adding a namespace, but then figured out I didn't find a good one so I gave up.
Anyway, it's jus a character, but will save pain the day we will add a namespace (and for sure we forget about adding the \ :P).
I forget those all the time, and my whole project is namespaced (PSR-4 FTW :D). Random backslashes stuffed in code look out of place, so I use lots of
use statements.