Plugin validation inconsistencies
It’s very cool that a plugin not in the right place be found to appear properly in the plugin page. The description and all other pages extracted from the readme.txt work fine even if the files are uploaded inside another trunk folder under trunk.
I know, it’s not a bug, but a cool smart feature!
I spent 2 days modifying the headers of my plugin because I got a message stating something about “invalid headers”.
Why? because I SAW the plugin listed and every new version appeared correctly in the repository pages. The text in the extend/plugins/ pages changed accordingly with every change I made to the files… everything looked fine.
If the file had NOT been found, I’d had had an insight of what went wrong right?
So I accidentally “checked out a new copy” (that’s the way svn calls it, which seems to say in human no-geek-person language “you’ll about to get the files for the latest version”) inside trunk. That’s the logic thinking of a non-command-line expert. Where else would I put the new copy? If it had said “checkout the whole repository” I had selected the root of my local folder.
Anyway, I ended up the whole thing, including tags and trunk folder, inside trunk.
Wordpress super cool system ACCEPTED IT to “display” it on the extend listing and pages, but FAILED to deliver it properly: For every download it sent the whole directory (tags and trunk).
So, the system which finds for the readme.txt looks EVERYWHERE in the folder.
Then, the core admin system finds for the plugin ONLY directly under the downloaded folder.
A little of consistency between both systems would have saved me 2 days.
- The topic ‘Plugin validation inconsistencies’ is closed to new replies.