Skip to content
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

Grab data parsed and generate custom post with metadata? #79

Open
dtygel opened this issue Sep 6, 2016 · 6 comments
Open

Grab data parsed and generate custom post with metadata? #79

dtygel opened this issue Sep 6, 2016 · 6 comments
Milestone

Comments

@dtygel
Copy link

dtygel commented Sep 6, 2016

Hi all,
What if the parser already being used could populate a wp_post and its metadata? The way it would work would be the same as now: a button in tinymce where user can put an url. But after url is passed, the content, description and metadata could be populated with the data grabbed. So we would not have a simple card, but a full post.

@khromov
Copy link
Collaborator

khromov commented Sep 6, 2016

@dtygel Thanks for your comment. What do you see as the use case for this? Enumerating all the embeds on your site? I think that's a good use case but something like mirroring other sites content is outside of the scope of this particular plugin.

@ideag
Copy link
Owner

ideag commented Sep 6, 2016

@khromov I think this idea has some merit. Storing all that stuff as a CPT would allow us to make Content Cards work outside of post scope (in custom wp_editor instances, sidebar widgets, etc.), as we would not really be tied to the post id as we are now, when we are using post meta.

Edit: I think it sould be a 'hidden' cpt (not public, not searchable, no admin UI, etc).

@ideag
Copy link
Owner

ideag commented Sep 6, 2016

It could certainly be helpful for #67 and/or #69.

@khromov
Copy link
Collaborator

khromov commented Sep 6, 2016

Agreed, that would help out. It would be a bit more complex than the postmeta storage but certainly doable.

Another option would be to use options table for storage. It would certainly be less code. 🐱

@ideag
Copy link
Owner

ideag commented Sep 6, 2016

@khromov options table is another option, true. I'm not sure which would be more maintainable in the long run. I somehow feel that storing data in a more structured manner (CPT+meta fields) would be better in the long run. It might also help us to fix the image caching issues we are having (or at least give us an easy way to nuke all cached images on uninstall, as they would be attached to certain posts. :)
P.S. I know feel is not a good argument here, but that's all I've got so far ;)

@dtygel
Copy link
Author

dtygel commented Sep 6, 2016

Having a full structured custom post for each card would allow for interesting template functions and filtering by the metadata.

@ideag ideag mentioned this issue Jan 7, 2017
6 tasks
@ideag ideag added this to the 1.0.0 milestone Jan 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants