Digidog's issues on drupal.org

After chatting with RobLoach and cweagans on IRC it came to the agreement that the configuration form link should rather point to admin/config/development/jquery_update then to performance like it is now.

Ok, here we are. Patch follows in the next hours

Currently the grouping options are shown all the time, though this is a) quite confusing b) it's not really clear that this options are connected with the grouping field just by looking at it visually.

What about adding a dependency for a selected field.

Here are some screenshot

AttachmentSize grouping.png10.76 KB grouping1.png22.88 KB

here a full node with CLE

AttachmentSize Workspace 1_061.png115.54 KB

Inspired by this discussion http://drupal.org/node/951088

but with some modifikation, I have added the possibility to check the option that all the local task tabs move into the nice contextual links hover menu and that it also appears on full node views and not only on list pages.

As mentioned here http://drupal.org/node/1366628#comment-5564012 from tomceek correctly, the solution to solve the issue #1366628: Warning: strpos() expects parameter 1 to be string, array given in _link_sanitize()...Line 509 of link.module. is rather an option than a whole take off or cut of failing code, since some may would like to play around with it a little bit more.

But finally I came to the conclusion that it makes more sense to better inject a more "complete" solution for an optional automatic rel removal if link is internal or external (depending on settings). By default the setting is to leave rel as set up before.

This way it makes it possible to decide for best practicees on the project with links from the admins side.

I don't want the user to enter a link. I just want a link to be showed to the user, so he can click on it and get directed to the corresponding node. Can this module do this?

Thank you very much.

Nico

While working on this #1417520: Fire hook_field_load and hook_field_attach_load for fields when aggregation is used. I came across the notice Array given, but string expected as argument 1 for unserialize() in _link_load():315.
This happens because the view's patch I'm working on fires hook_field_load() and hook_field_attach_load to ensure the data are consistent after the rewrites took place.
I'd suggest to add a condition before user unserialize to avoid such errors.
In my eyes a second call to _link_load() shouldn't lead to an error (even if I know it's hackish what I try to do with views ;) ).
The attached patch might also solve this issue #1374928: Array given, but string expected as argument 1 for unserialize() in _link_load():315 (when title-attribute is user defined)

The patch contains:

• Condition before unserialize in _link_load()
• link_views_handler_argument_target::query() is now compatible to its parent to avoid php strict notices
• Traling whitespaces removed as described in the coding standards.

AttachmentSize link-dont-unserialzed-already-unserialzed-attributes.diff3.03 KB

I am trying to use the built-in "link-title" token as the "title" attribute on the field setup page. By default, if left with basic settings, the title field for each URL does not get added as the title attribute for the link.

Therefore, I tried to set the "Link 'title' Attribute" at the bottom of the field setup page to use this token, to force the attribute to be created on the link element and use the text the user entered as a title for each URL.

However, when saving the node, the link module is only using the last field item's token value and applying it to all of the URLs added in this multiple (Unlimited) values CCK field.

Unless I'm missing something, I see this as a critical bug. Can anyone suggest a patch if so?

Example

Entered as ([Link Title] | [URL]):

Find me on Facebook | www.facebook.com/userX
Follow me on Twitter | www.twitter.com/userX
Join me on LinkedIn | www.linkedin.com/userX/view

Is rendered on the node and in the database as:

<a href="www.facebook.com/userX" title="Join me on Linked In">Find me on Facebook</a>
<a href="www.twitter.com/userX" title="Join me on Linked In">Follow me on Twitter</a>
<a href="www.linkedin.com/userX/view" title="Join me on Linked In">Join me on LinkedIn</a>

Note here all three different links are using the last link's title.

If I add a link to a node and the page title is "Now & Then" the &-sign is replace by %26 and my link is invalid.
Can you please fix this? Every link is dead with the &-sign.

Hi,
I have a link field that is correctly storing <front>. I've trawled through the module code a little and it is correctly being validated as LINK_FRONT. However, when the node is displayed, the link looks like this:

<a href="/%26lt%3Bfront%26gt%3B">Find out more</a>

I'm not sure why. Can anyone help please?

If you require any further info, please just let me know. I'm using D7.10

Matthew

Link to the spam comment:

http://api.drupal.org/api/drupal/modules--system--system.api.php/functio...

posted 27. Jan 2012

There is a problem with the string:

t('The link title is limited to '.$settings['title_maxlength'].' characters maximum.')

It don't use variable replacement in t() function and makes not possible to translate this string.

Link module code have some collission with Drupal coding standards. We have to review the code with coder module and resolve found problems.

I've been impressed by theverge.com's structural design of it's articles, and it's ability to show contextual content. I've been thinking about how something as flexible can be accomplished with Drupal. I believe the key to it involves field collections, so that's why I'm posting this here. What follows is more of a vision/hope for what field collections could grow into.

Field collections are a way to structure singular or repeating "field sets". Collections are re-usable and most likely one field collection by itself would not consists of an entire page's contents. Right now field collections have to be created on the content type they are associated with and then the collection has its fields added and edited separately. Then this field collection be can added again and again to other content types. I believe a more robust solution would be if instead of adding one field collection as a node's field, you would add a field collection selector.

When adding the field collection selector, you choose what collections are available to the end user. When the end users clicks "Add" button they now have a list of options to choose from that have been crafted by the designer. Designers can now craft field collections as different elements of a page, and those elements can be created and placed in any order the end user desires.

Here is an example of how an article from the verge would breakdown. (The breakdown) with field collections selectors.

That page requires at most four field collections...

• Banner Image,
• WYSIWYG
• WYSIWYG with Sidebar
• Centered Images

The field collection selector could be built a top the entity reference module, but it would require figuring this out #1261574: Create reference if it doesn't exist first.

The icing on the cake, would be to have some form of visual sorting for the field collections. That way a user could drag and drop the content to re-order them as they see fit. The "Draggable Views" module can already can do this for nodes, but it doesn't yet fully work with field collections.

I would appreciate any thoughts on this.

When submitting a form with a link field that has a invalid URL, a validation error message is shown but the field isn't highlighted (it hasn't the "error" class).

I've attached a screenshot of it in a clean Drupal installation.

AttachmentSize Create Page | Link.png121.1 KB

Not sure from where to where the dependencies go here, but after git pull origin 8.x and cache/db refresh I get about xx lines of this notice with changing modules affected all over the place:

   
Notice: Undefined property: stdClass::$langcode in drupal_lookup_path() (line 77 of /home/digidog/www/drupal8/core/includes/path.inc).
    Notice: Undefined property: stdClass::$langcode in drupal_lookup_path() (line 77 of /home/digidog/www/drupal8/core/includes/path.inc).
    Notice: Undefined property: stdClass::$langcode in drupal_lookup_path() (line 77 of /home/digidog/www/drupal8/core/includes/path.inc).
    Notice: Undefined property: stdClass::$langcode in drupal_lookup_path() (line 77 of /home/digidog/www/drupal8/core/includes/path.inc).
    Notice: Undefined property: stdClass::$langcode in drupal_lookup_path() (line 77 of /home/digidog/www/drupal8/core/includes/path.inc).
    Notice: Undefined property: stdClass::$langcode in drupal_lookup_path() (line 77 of /home/digidog/www/drupal8/core/includes/path.inc).
    Notice: Undefined property: stdClass::$langcode in drupal_lookup_path() (line 77 of /home/digidog/www/drupal8/core/includes/path.inc).
    Notice: Undefined property: stdClass::$langcode in template_preprocess_html() (line 2356 of /home/digidog/www/drupal8/core/includes/theme.inc).
    Notice: Undefined property: stdClass::$langcode in drupal_lookup_path() (line 77 of /home/digidog/www/drupal8/core/includes/path.inc).
    Notice: Undefined property: stdClass::$langcode in admin_menu_init() (line 145 of /home/digidog/www/drupal8/sites/all/modules/admin_menu/admin_menu.module).
    Notice: Undefined property: stdClass::$langcode in drupal_lookup_path() (line 77 of /home/digidog/www/drupal8/core/includes/path.inc).
    Notice: Undefined property: stdClass::$langcode in _node_types_build() (line 685 of /home/digidog/www/drupal8/core/modules/node/node.module).
    Notice: Undefined property: stdClass::$langcode in _node_types_build() (line 685 of /home/digidog/www/drupal8/core/modules/node/node.module).
    Notice: Undefined property: stdClass::$langcode in drupal_lookup_path() (line 77 of /home/digidog/www/drupal8/core/includes/path.inc).
    Notice: Undefined property: stdClass::$langcode in drupal_deliver_html_page() (line 2469 of /home/digidog/www/drupal8/core/includes/common.inc).
    Notice: Undefined property: stdClass::$langcode in _node_types_build() (line 685 of /home/digidog/www/drupal8/core/modules/node/node.module).
    Notice: Undefined property: stdClass::$langcode in menu_tree_page_data() (line 1217 of /home/digidog/www/drupal8/core/includes/menu.inc).
    Notice: Undefined property: stdClass::$langcode in _menu_build_tree() (line 1369 of /home/digidog/www/drupal8/core/includes/menu.inc).
    Notice: Undefined property: stdClass::$langcode in _node_types_build() (line 685 of /home/digidog/www/drupal8/core/modules/node/node.module).
    Notice: Undefined property: stdClass::$langcode in _node_types_build() (line 685 of /home/digidog/www/drupal8/core/modules/node/node.module).
    Notice: Undefined property: stdClass::$langcode in admin_menu_output() (line 375 of /home/digidog/www/drupal8/sites/all/modules/admin_menu/admin_menu.module).
    Notice: Undefined property: stdClass::$langcode in menu_tree_page_data() (line 1217 of /home/digidog/www/drupal8/core/includes/menu.inc).
    Notice: Undefined property: stdClass::$langcode in _menu_build_tree() (line 1369 of /home/digidog/www/drupal8/core/includes/menu.inc).
    Notice: Undefined property: stdClass::$langcode in menu_tree_page_data() (line 1217 of /home/digidog/www/drupal8/core/includes/menu.inc).
    Notice: Undefined property: stdClass::$langcode in _menu_build_tree() (line 1369 of /home/digidog/www/drupal8/core/includes/menu.inc).

Hm ... To make sure that I didn't double notice occuring by content, I have deleted all content before. So we have a naked and clean 8.x mirror here from issue creation time stamp.

I've spoken with sun, RobLoach, catch and webchick on IRC #drupal-contribute and - if I'm not mistaken - there was a accordance to that we actually need at least 3 issues/solutions to solve issues like #87994: Quit clobbering people's work when they click the filter tips link

... the one which already exists (link above) to approve that we can access any handler successfully to change filter tips link behaviour, another one (this here) to extract that drupal_add_effect() handler code arosed over there in the other issue, to have it understood as an own task for many use-cases and ... (not sure about that) maybe other handlers as own issues (?) or all together with this one here, since we can see it as one handler with 3 or more options to choose from.

Why I choose theme system can be read here http://drupal.org/node/87994#comment-5459474. I could think of them being available as checkboxes in appearance/YOURTHEME/settings defaults. But maybe it is better to have them as checkboxes on the content type creation/edit dialogs. Not sure about that. Maybe this needs to be discussed. Feel free to correct my choice.

And a third one for jQuery UI version 1.9 and higher to make sure that we can use all improvements from jQuery's next big releases. The issue also already exists here -> #1085590: Update jQuery UI to the latest in the git repository

I will reroll the patch from #87994 against core regarding to this issue here to start from there. Credits for the patch go to the contributers in the #87994 issue, not to me.

(I also would like to have an opinion from core maintainers like chx in connection with the cleaning initiative and its reasonable priority, if it is possible to have it backported in D7 to get rid off the filter tip link disaster)

User page seems to be deleted already ?? not sure ...

http://api.drupal.org/api/drupal/includes--common.inc/function/l/7#comme...

The module css provides a custom clearfix:after in line 834 of the calendar_multiday.css, which makes all views sadly clear, and what can make some css grids collab when the .view-content div is wrapping a grid div, which is classified as column instead of a row. Since .view-content css class is used by all rendered views I would like to suggest the Drupal class .clearfix as class attribute, which is mostly fine.

To reproduce: If you use a css grid or anything what makes your blocks and regions flexible for responsive web design you may or may not come to the point, where some views regions suddently start to get displayed as block instead of an inline region to each other. In the worsed case you sot there for 2 hours like me, to find out, that the views css which you alreaday know deeply has got hijacked from calendar css to make the .view-content div using its own clearfix. zzzong ... Of course, you can reset that again in your own css, but it depends on weight and use case if this will work in every situation.

Patch follows next hour ...