#3694 closed enhancement (wontfix)
Add hooks to class-parser.php
Reported by: | afragen | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Plugin Directory | Keywords: | has-patch dev-feedback |
Cc: |
Description
Many plugin developers use various readme parsers in their plugins. All of these need to be modified for use inside of the plugins. By adding a couple of hooks to class-parser.php
; plugin developers will be able to better utilize the parser inside of plugins.
Use Case:
I utilize the class-parser.php
inside of a plugin to parse readme.txt
files that exist outside of the dot org repository. In order to currently accomplish this I need to modify the class-parser.php
file. Adding these hooks will allow for a drop-in parser that can be modified without modifying the core file.
N.B.: The attached patch shows the changes but I don't have a meta environment set up to properly create the patch.
Attachments (1)
Change History (9)
#1
@
6 years ago
As an example, here is my specific use case.
https://github.com/afragen/github-updater/commit/e4cbe01ae5e84f94e806c2607a894898e30ea47b
#2
@
6 years ago
Why either/or on reading the file? Why not just apply the filter to the file contents instead of to false? If you don't need the contents, then you don't use it.
#3
@
6 years ago
The problem becomes that I'm passing the file contents as a string into the parser. Running file_get_contents()
on this string causes a PHP Exception.
Running the filter on false allows for both situations to occur.
#4
@
6 years ago
I think you might be using the filter incorrectly. You would not file read the contents of the first parameter, but the second one.
#5
@
6 years ago
That’s quite possible. My intent is to pass $file to the filter and return $contents. If the filter is not used or doesn’t return $contents, like on dot org, it would return false and then $contents would be set to file_get_contents($file).
Am I explaining this correctly?
#6
@
6 years ago
@Otto42 the filter may look a bit backwards because it’s really designed to use when the file is utilized in a plugin. When used on dot org it should behave similarly to how it currently behaves.
I appreciate your feedback, thanks. I really want to get this right so that I, and others, can utilize class-parser.php in our plugins without modification.
#7
@
6 years ago
- Resolution set to wontfix
- Status changed from new to closed
Parts of the plugin directory aren't designed to be used stand alone, and building things to support that isn't exactly ideal in many scenario's.
The plugin directory classes may (and will) change with zero back-compat thoughts.
With the above in mind, I don't think this change is one that should be made.
If you do want to use it with a string you have, I'd suggest either a temporary file for it, or using the PHP data:// wrapper which should work for your use-case.
#8
@
6 years ago
@dd32 thanks for the help in figuring out a work around.
My real issue was that I already had the file contents as a string and class-parser.php
takes a file path. I simply wrote out the file contents back to a temp file and then passed the new file path on.
Thanks for encouraging me to look deeper for a solution without modifying this core file.
Andy
Addition of hooks to
parse_readme()