-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework plugin to use filters/hooks that enable easy addition of new video providers #49
Comments
You've got my attention. 👀 |
the latter regarding interface. Think how Woo/EDD/etc all allow for easy addition of payment gateways. |
So we're on the same page, here is my rough understanding.
That will allow us to check each provider prior to executing the logic. Something along the lines of:
Do you want to break it down into smaller tasks? I don't know how much time I can put into it, but I'm really excited by the approach. |
I'm assuming I'll be doing a lot of the initial legwork, and I definitely need to break it all down into smaller details to help anyone looking better comprehend. I also wager this will be a bigger overhaul than what has gone on in 1.1.0's changes, which have been mostly minor details, outside of the bulk processing. |
I want/would like this as planned out, discussed, debated, and documented ahead of time as we can manage, before any code gets written. That way we can cover all the nooks and crannies and details. Bit more detail about what provides what:
In the process discovery method, it would probably be a good idea to stop the process once we've found something. Say we have 3 urls all within that character limit. Should we stop after the 1st one? Or let it do all 3 and just have the 3rd one "win". Potential to muck up media libraries with items not used. |
My vote is for stopping the process after the first match for the reasons you mentioned. I'm a little confused as to architecture based on the first sentence though? Do you have a rough sketch or even directory structure? |
I could see myself going either way for a static property vs a getter/setter setup, if not just simply assigning during instantiation. Which first sentence? The one about planning everything ahead of time? or just the base class part? My thoughts were that we handle certain parts, the providers handle other parts. Specifically, we handle stitching it all together as much as possible, the providers primary goal is to provide the values/threads, to go with this example. Extending would make sure the instances have a single, consistent method that we control in the parent, while the interface makes sure they've provided the methods for site-specific information. |
Sorry for the ambiguity. Can you perhaps layout the dir/file structure as you see it? |
I'll brain on that and try to get back to this soon. |
Would need to have a way to provide the following:
Registration of the video service.
Location of video URL
Regex provider to parse out URL specifics like video ID, etc.
Interface/methods to take the found ID/data and make API HTTP requests to provider to return an image, upload, and attach.
Methods to set the various meta data that we will have by the time this feature is started and completed.
The idea is to make it as simple as possible to provide a new video service, and separate out logic/concerns as best possible into individual classes.
The text was updated successfully, but these errors were encountered: