Capturing hrefs pulls & as urlencoded

[benwrigley]

I'm not sure if this is correct behaviour, but I noticed this has changed since last release:

here is an example of a link I am capturing

<a href="?search=Fort+William&session_type=face&distance=100&uqs=119846&page=4" class="pagination-next">Next <span class="chevron">&gt;</span></a>

when I dump the href

?search=Fort+William&session_type=face&distance=100&uqs=119846&page=2

Is there a way to turn of urlEncoding (assuming that's what it is?)

Thanks, great tool BTW!

[jkappel71]

I'd be very interested in turning that off as well.

[paquettg]

Hey @benwrigley,

I added a test using the string you gave me and I was not able to reproduce the issue. Can you look over the test and see how it is different from how you do things on your end.

[benwrigley]

Hi @paquettg,

Thanks so much for looking into this and my apologies. In Chrome when I inspect the link I see & but if I view the page source I see &, so that is the reason why.

However, I understand this is best practise now, so more and more sites will be doing this.

I wonder if it worth decoding it anyway because as soon as I try and submit the link using Guzzle it won't work. However, you could also argue that's a Guzzle issue.

so test would need to be

    public function testGetComplexAttribute()
    {
        $dom = new Dom;
        $dom->load('<a href="?search=Fort+William&amp;session_type=face&amp;distance=100&amp;uqs=119846&amp;page=4" class="pagination-next">Next <span class="chevron">&gt;</span></a>');
        $href = $dom->find('a', 0)->href;
        $this->assertEquals('?search=Fort+William&session_type=face&distance=100&uqs=119846&page=4', $href);
    }

What do you think?

[paquettg]

We can add an option to parse the & and other html tags. This would be a new feature so I'll mark it as such but I don't see why we can't add that.

[benwrigley]

@paquettg Thank you so much! Look forward to it.