Link field work and improvements

[JoryHogeveen]

Is it possible to add a Link field to Pods?
Would be a bit similar to a Website field I think.

• URL (possible with the Link feature from wordpress itself so you can select the page to link to.
• Title
• Target

Could be separate metadata in the database or a serialized array.

Last items for Pods 2.7 #4068

• What to do if the user changes the field type from Website to Link and vice versa?
  See: https://github.com/JoryHogeveen/pods-link-field/blob/master/classes/fields/link.php#L252-L255
• Add an option to set the default target value to _blank
  See: JoryHogeveen/pods-link-field@5a07ddd
• @sc0ttkclark Do you want to enable other storage types as well? It currently only stores as a serialized array

[Shelob9]

We are not adding any new features to Pods 2.X. Once we finish the cmb2 integration for Pods 3.0 we can address new field types. This would be one be very nice to have, possibly as a specific type of loop field.

[JoryHogeveen]

Is there a guide/howto on creating extra field types? I would like to try and start with this field on the 3.0 release.

[sc0ttkclark]

If you can start with building the frontend for it and how it would work / look (using the same aesthetics as WP), I can meet you in the middle and help you adjust the current website field to support this field format.

[JoryHogeveen]

Hi Scott, I assume you mean wireframes and a HTML version of the a link.php template (ui/fields/link.php)?

[sc0ttkclark]

Yes, I'd like to see some frontend markup and styling for how you envision it looking.

[JoryHogeveen]

This is how I would see this working. Especially the popup feature would be neat.

HTML version for the file link.php in ui/fields:

<div id="link-options">
    <p class="howto"><?php _e('Enter the destination URL') ?></p>
    <div class="alignleft">
        <label><span><?php _e('URL') ?></span><input id="url-field" type="text" name="href"></label>
    </div>
    <div class="alignleft">
        <label><span><?php _e('Title') ?></span><input id="link-title-field" type="text" name="linktitle"></label>
    </div>
    <div class="link-target">
        <label><div>&nbsp;</div><input type="checkbox" id="link-target-checkbox" style="display: inline-block;"> <?php _e('Open link in a new window/tab') ?></label>
    </div>
    <p class="howto" style="clear: both;"><a href="#" id="wp-link-search-toggle"><?php _e('Or link to existing content') ?></a> (Popup WYSIWYG Link feature &amp; autofill above fields)</p>
</div>

[JoryHogeveen]

I've searched some extra info on the WYSIWYG link feature. Is done with a javascript class (wp-includes / js / wplink.js) and i'm afraid its build for the editor only. We could use this as a blueprint for this field...

[JoryHogeveen]

An class on this feature: wp-includes / class-wp-editor.php

lines:

• 1231 - 1232
• 1434 - 1499 ( wp_link_dialog() function )

[sc0ttkclark]

Great research here, would love to find ways to integrate into the link to existing and figure out how to utilize all of this on non post editor areas like user edit / taxonomy term add/edit, or even on the frontend of a site.

[sc0ttkclark]

UI of the field looks great to me by the way

[quasel]

+1 looks good

[Dooza]

Just wondering how this one was progressing as I have a need for it.

[JoryHogeveen]

It doesn't have a contributor yet as I can see so far.

Scott, I would like to help in the development on this though I think I will need some help from a Pods developer.
Can I find some quidelines for developing in Pods? And is the latest version on GitHub stable enough for development and testing?

[JoryHogeveen]

Also, here is a plugin for ACF witch does a simpler version of what we want to do:
https://wordpress.org/plugins/advanced-custom-fields-link-picker-field/

[Dooza]

That is exactly how it should look, no point reinventing the wheel.

[sc0ttkclark]

@JoryHogeveen sorry for not getting back to you. Do you want to tackle these things in 2.7 or can we push them to later?

[JoryHogeveen]

@sc0ttkclark I'd like to tackle these for 2.7 since I believe it will raise a lot of support questions otherwise.
Also.. I already have it fixed for the most part so why not... I posted it here to ask your opinion.

The first item is about making some fields compatible with eachother when switching.
Website -> Link and Link -> Website.

The last topic is your area so I'll leave that up to you.

[jimtrue]

Never actually tested this one, sorry. Output isn't correct in a Magic Tag (ie we should just be able to go {@link_field} and it do all the necessary wrapping, etc.

this is what it outputs: and _blank

I think because it's actually built as an array, it output it as a display() list, so url, text, and target. It should actually construct the link.

[jimtrue]

ie, it should have a special handler for display() like your output as gallery option.

[quasel]

While this is a neat idea it might lead to confused users - just adding a field should I use link or Website? whats the difference? In my opinion this two fields need to be combined and act like the image stuff to be consistent!

• needs magic tag support maybe including stuff like for images _src / _schemeless
• needs display() support

@sc0ttkclark @JoryHogeveen - do you want another issue? for the time being I just reopened this one!

[sc0ttkclark]

I think you're right, we need to differentiate these two field types much better in describing/naming them. As far as combining them, there's some technical issues to overcome, one is a text input and the other has a few different parts to it.

Magic tag / display support could probably be improved too, I'm open to potentially putting this new field type inclusion on hold until we get the naming thing sorted out. We could comment out the link field type inclusion pretty easily in PodsForm.

[quasel]

At least until the output for dispaly and magic tags works correctly we should not put it out in the wild - i like the new approach and i would see it as a superior solution - maybe we can convert the old field to it and add a option in the configuration? something similar to how images work or we add another group of "URL" Kind of fields ...

@reachadam from WPCrafter already asked me about the weird output ;)

[JoryHogeveen]

Let me know if you have any ideas for combining these fields. With these changes I think renaming the Website field is mandatory since I don't think it described exactly what is done here.
We could just rename the label to "Website / Link" and merge all the Link functionality into the Website field class with an option to enable/disable it?

[jimtrue]

My thought would be if you checked the 'link' button, that's when the additional options would show up because then they would be needed. Typically the website field would be designed to contain the URL portion of the 'link'.

I've always felt the Website field is actually a URL field. I use it for that with YouTube links, Slideshare, etc. The old 'link' post type that was part of WordPress was designed more like you've set this one up to be. If we were to combine them, the other options should only show if you want the 'link' to be handled automatically with echo $pods->display('url_field'); or {@url_field}, which ideally, display and magic tag display should be identically handled. The only time it would return the array setup would be if you did a $pods->field('url_field');

[quasel]

Idea / Summary:

• link_field display and magic tag of the field per default returns the url as configured - Like the "Gallery" Feature you can opt in to output a full "link"
• link_field._src just the plain url
• link_field._src_schemeless
• link_field._src_relative
  and for the full output? _link or _url or ^^^^ like it's done for images and files
• link_field._link always puts out a full link if no "text" is configured the url is used as text too and _blank
  ...

maybe not the best approach but seems inline with the current options for files / images / and it should work for "old" and "new" thoughts?

[pglewis]

Is this still planned to make 2.7?

[sc0ttkclark]

Do we have a list of todos left on this or are the remaining things left just nice-to-haves? Should we punt to 2.8?

[JoryHogeveen]

I think we'll need to clearify what to do exactly first before we can create a todo list.
If 2.7 will release on aug 15th as planned according to the milestone I think it's better to punt to 2.8 or a 2.7 maintenance release

[JoryHogeveen]

New request/vote for this field: https://wordpress.org/support/topic/custom-fields-to-store-link-and-its-description/

[JoryHogeveen]

Another user requesting the same feature: https://wordpress.org/support/topic/website-repeatable-title/