Upgrade breaks MLA

Thanks for your report – I’m sorry to hear you’re having such a problem with the upgrade, especially on a client site.

When you write “if I update“, I assume that means you are trying to update MLA to the most recent version (2.14); is that right?

When you write “everything associated with MLA stops working“, does that mean all of the MLA admin screens stop working? Does that include the Settings screen? What happens when you try to access those screens?

When you write “individual image pages” are you referring to the front end “media/attachment page” for a single image? I checked out a few pages on the site and found these “individual image” pages:

https://www.ursulavonrydingsvard.net/process/99-2014-bentlace-1/?attachment_tag

That looks like some sort of lightbox display.

Do you have access to the site’s error log? Can you modify the wp-config.php file to define( WP_DEBUG, true ) and see if there are PHP messages written to the log?

I haven’t tried to jump from version 1.9 to 2.14, but I cannot think of a reason that it wouldn’t work. If you can give me more information about what’s happening on the site I can investigate further. Thanks for your understanding.

Hi David, I will try to be more clear. Thank you for your quick reply

If I update – yes, from 1.90 to 2.14

It seems that the complicated shortcodes don’t work to display anything on the frontend anymore for some reason. The backend looks fine, and the :”individual image” pages will display the image, but not the forward/back links that depend on the short codes.

I turned the debug on.. and I get this on the image page:

Notice: Undefined variable: PriImgId in /home/uvrweb/ursulavonrydingsvard.net/wp-2014/wp-content/themes/UvR-Template_twentyfourteen-child/functions.php on line 85

Sorry – – I just tried to change the short code, and this is what seems to be breaking the Sculpture page:

attachment_tag=”{+request:term_id+}”

Thank you for all your testing and for your updates. I am still at a loss to explain what’s going on.

I looked more closely at the example page you gave in your first post. The URL you gave ends in “attachment_tag” without a tag value; it should be something like attachment_tag=some-value. Whatever is generating the URL is broken in some way. The “Previous Image” and “Next Image” URLs include attachment_tag= again without a value. That’s probably because the original URL does not supply a value. If you can find the cause of the missing value the problem may be fixed.

Have you looked in your theme’s functions.php file to see what’s happening around line 85? If you revert to MLA 1.90 does the “Undefined variable” message go away?

There’s nothing unusual about the shortcode parameter you included in your post. You can try surrounding your shortcode with <code></code> tags. WordPress changed the way it parses shortcodes in a way that sometimes gets confused by complex [mla_gallery] shortcodes.

Hi there – – I rolled everything back to 1.90. If you’re available now, I can update again so you can see the issues? I will wait for your response.

If your site is currently on MLA v1.90, the problem is not related to an upgrade to v2.14. I just accessed the site and went to:

https://www.ursulavonrydingsvard.net/process/

All of the URLs behind the images on that page are missing argument values. Here’s an example:

https://www.ursulavonrydingsvard.net/wp-2014/?p=2068&current_id=2068&attachment_tag=&group=

The source of your problem is on the /process/ page. Can you post the source text of that page or at least any 'mla_gallery] shortcodes that are generating the bad URLs?

[mla_gallery attachment_category=”mla-process” attachment_tag=”{+request:term_id+}” mla_link_href=”{+site_url+}/?p={+attachment_ID+}&current_id={+attachment_ID+}&attachment_tag={+query:attachment_tag+}&group={+query:term_taxonomy_id+}” orderby=slug order=DESC columns=0 post_parent=current ]

Thank you! The problem is something related to the query: parameters in this shortcode. Can you confirm that the example I just gave above used v1.90?

confirmed.

As I posted, the query: parameters are causing the problem. The MLA Documentation says:

The parameters defined in the [mla_gallery] shortcode. For example, if your shortcode is [mla_gallery attachment_tag=my-tag div-class=some_class] you can access the parameters as [+query:attachment_tag+] and [+query:div-class+] respectively. Only the parameters actually present in the shortcode are accessible; default values for parameters not actually present are not available. You can define your own parameters, e.g., “div-class”; they will be accessible as field-level data but will otherwise be ignored.

This suggests that you can replace attachment_tag={+query:attachment_tag+} with attachment_tag={+request:term_id+}. However, term_id would have to be set in the URL that gets you to the /process/ page and I don’t see how that is happening.

I also don’t see how the group parameter can work, since term_taxonomy_id is not present in the shortcode. It looks like the shortcode is using query: to refer to the SQL query, which is a misunderstanding.

On a completely separate note, you may be having trouble with the ampersand characters in the mla_link_href parameter. Recent WordPress changes to shortcode parsing sometimes damages these. You can try replacing the ampersands with the ampersand-amp; equivalent.

Hi there – – I just updated it to 2.14, removed the group and attachment_tag from the mla_link, and updated the & – – – and it’s not working.

If I delete attachment_tag=”{+request:term_id+}” it works.

If it’s a problem with the term_id, I don’t understand why it would work in 1.90, but not in 2.14?

Thanks for sticking with me on this. You wrote “If I delete attachment_tag=”{+request:term_id+}” it works” – does that mean that the previous/next links are working?

As I understand it, the “Process” page shows everything in attachment_category="mla-process". When you click on one of the thumbnails you get a larger version of the single image. On that page, the previous/next links should move you through the images with attachment_category="mla-process". Is that right? Is that working?

If the above is right I do not see how attachment_tag was intended to be used. Removing it should be harmless.

I suspect that changes in WordPress (or perhaps MLA) have changed the way an empty taxonomy query is processed. In the old days, attachment_tag= matched everything, now it matches nothing.

Is there more to be debugged/done?

Your kindness and responsiveness on this is astounding! Thank you much.

Yes, it seems that, even though it worked in 1.90, it was all superfluous anyway. I’ve deleted that bit of code across the board and everything seems to be working (though it’s still slow! – but I have another ticket open for that and I will investigate your suggestions). I think all is right again with the world.

BTW — L’Shana Tova, my friend. Thanks again!