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

Repeated epc:pin with same name are not replaced correctly #424

Open
mpbraendle opened this issue Oct 26, 2016 · 4 comments
Open

Repeated epc:pin with same name are not replaced correctly #424

mpbraendle opened this issue Oct 26, 2016 · 4 comments

Comments

@mpbraendle
Copy link
Contributor

mpbraendle commented Oct 26, 2016

Background:
phrase file with an epp:phrase with multiple epc:pin that have the same name value.

A static page (.xpage) or a template with
<epc:phrase ref="somephrase"><epc:param name="pinname">some pin value</epc:param></epc:phrase>

only replaces the first pin, the remaining pins lead to an empty value.

The same is true for
$session->html_phrase( "somephrase", pinname => $session->make_text( "some pin value"))

@phluid61
Copy link
Contributor

Seems strange, EPrints::XML::EPC::_process_pin does a whole song and dance about cloning XML nodes for subsequent instances. EPrints::XML::clone_node seems to do the right things. We'll have to try to isolate it somehow.

(Note to self: EPrints::Repository::html_phrase > EPrints::Language::phrase > EPrints::XML::EPC::process_child_nodes > process > _process_pin)

@jesusbagpuss
Copy link
Contributor

@drn05r - your post to the EP-Tech list last night reminded me of this.

Wasn't sure if this needs Issue creating in 3.4 too?

@drn05r
Copy link
Contributor

drn05r commented Nov 13, 2020

On 3.4 this still seems to be present but only in some scenarios. If the phrase is in an archive level phrases file then it seems to work fine. However, when the phrase is elsewhere, in my case where it is part of a 3.4 ingredient the pin becomes empty after its first use. I am unsure why this is. I hope to make a deeper investigation on 3.4 later this afternoon.

@drn05r
Copy link
Contributor

drn05r commented Nov 24, 2020

I have applied the following patch to 3.4 to 'fix' this. However, I am unsure whether it will have unintended consequences:

diff --git a/perl_lib/EPrints/XML/EPC.pm b/perl_lib/EPrints/XML/EPC.pm
index b33c7e5..bb5d76f 100644
--- a/perl_lib/EPrints/XML/EPC.pm
+++ b/perl_lib/EPrints/XML/EPC.pm
@@ -167,15 +167,10 @@ sub _process_pin
        }


-       my $retnode;
-       if( $params{pindata}->{used}->{$ref} || $node->hasChildNodes )
-       {
-               $retnode = EPrints::XML::clone_node(
-                               $params{pindata}->{inserts}->{$ref}, 1 );
-       }
-       else
+       my $retnode = EPrints::XML::clone_node( $params{pindata}->{inserts}->{$ref}, 1 );
+
+       unless ( $params{pindata}->{used}->{$ref} || $node->hasChildNodes )
        {
-               $retnode = $params{pindata}->{inserts}->{$ref};
                $params{pindata}->{used}->{$ref} = 1;
        }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants