ph_remy

@cais,

For reference purposes, the js library that does the trick is called touch-punch, and can be found at https://forresst.github.io/2012/06/22/Make-a-list-jQuery-Mobile-sortable-by-drag-and-drop/. Works if only including jQuery UI scripts. Mixing jQuery UI and jQuery Mobile is not guaranteed to work…

Solving the problem caused by the removal of the script is “as simple” as renaming the script so that it does not include the words containing the combination of jquery and ui. Another option which I have not tested would be to enqueue the script (without renaming) with a very low priority, ie, after NextGen has loaded its own scripts and removed the ones it does not “like”.

Solution tested on the Mac iOS Simulator for iPad.

Will report the bug as suggested, with indications of where the “culprit” code can be found.

Will mark the topic as resolved, since I cannot think of anything to add.

Kind regards,
Philippe

@cais, Sorry to disagree, I just spent two hours to understand why one of the scripts I am using was not getting enqueued when on the admin pages of NextGen Gallery while it was getting enqueued on all other admin pages.

After these two hours of cursing :-((, I finally found the code in class nggAdminPanel, method output_scripts, and could see in debugging that it was indeed removing the script I needed. NextGen does NOT reinstate those scripts, I do not need to debug/review the whole code, the results are clearly visible since the drag and drop on iPad does not work when letting NextGen follow its course, and the script is nowhere to be seen on the NextGen Admin Pages in Chrome, Safari or Firefox developer tools. But when I force NextGen to “bypass” that piece of code, the script I need is correctly loaded, it is visible in the browser developer tools, and the drag and drop/sortable works on iPad.

Do not misunderstand me, I am not “angry” or “furious”, I have been developing fairly complex functions on SAP (ERP software used by Fortune 500 companies) for over 20 years, so, I know that development is a complex process and that bugs are inevitable.

If this case is an instance of a bug having gone unnoticed, then of course, I will be more than happy to submit a bug report. If, however, the code is intentionally removing custom scripts without any intention of reinstating them, that is a totally different matter…

Philippe

Hi,

Actually, I found a js library that does add support for Sortable on iPad, which works wonders. BUT, and this is where I am raising my eyebrows towards some code in NextGen, NextGen removes any custom jQuery UI Script: comment in code is extremely specific:

// Detect custom jQuery UI script and remove

I may be wrong, but as far as I am aware, it is not considered good practice for plugins to remove code, css, scripts from other plugins or themes, even if it is for the sake of avoiding conflicts, especially without any notice or indication to anyone that this is indeed happening.

I checked on the plugin page, and unless I missed it, nowhere is there a mention that NextGen Gallery removes custom jQuery UI scripts, nor is there any mention that custom (non-NextGen Gallery) jQuery UI scripts may cause conflicts with NextGen Gallery. If such is the case, I would strongly urge Photocrati to issue very clear warnings/statements to the effect that custom scripts may get removed by NextGen Gallery, with an indication of the reasons why this is done, and at least hints as to what can be done to avoid potential conflicts.

Anyhow, I will find a solution, but the implications of the code I found are somewhat “disturbing”, as NextGen Gallery could very well break other legitimate plugins just to safeguard the stability of their own product. In any event, thanks for your reply.

Best regards,
Philippe

@cais – Many thanks. Had not seen the reply from Mike yet! Best of luck with the fire-fighting ;-))

@cais – If you have any opportunity to relay messages back to Photocrati, there is a desperate need for more documentation on the Pope Framework, the NextGen data model, on Display Types (the tutorial How-to: Build a Display Type simply does not work as is), and on how to customize. For instance, there are “pre-hooks” and “post-hooks”, which sound like a pretty powerful feature of the Pope Framework, but with no documentation or tutorials, it does not matter how powerful the framework actually is: hardly anyone outside of Photocrati can use/understand it, and therefore help others to solve their issues in NextGen. In the long run, this cannot be good for the product. Just my 2 cents worth…

Hi, Sylgour,

First of all, thank you for getting back to me with the result of that little “update” change. It is always rewarding to know that I have been able to help.

How to not have to do the same again in the future: I have a strong suspicion that the “update” method has a bug in it, located just after the line where I suggested to “force update”, but have not progressed the debugging further yet to ascertain the bug. If/when I do, I will report the bug to Photocrati.

As to reverting back to an earlier version of NextGen, I cannot say. The 2.0 version of NextGen has been a major overhaul (complete rewrite), with a switch to the MVC (Model-View-Controller) programming paradigm. Given that WordPress itself is not MVC-based, but event-based, integration was always going to be challenging at best. Whether the teething problems of 2.0 are going to last much longer, I don’t know, it mainly depends on how much of an effort goes into addressing the known issues.

What does not help either is the lack of documentation/tutorials on the 2.0 NextGen architecture. NextGen 2.0 is based on a framework that was entirely developed by Photocrati, from what I understand. But there is very little in terms of developer documentation on that framework and how to use it properly, let alone on how to use it to customize NextGen (I just spent 4 heavy days trying to define of new Display Type, when in the old version, it was taking a few hours to define a new template).

Reverting to an earlier version (like 1.9.x) “might” lead to other issues: the uninstall script of 2.0 does not remove its data, and data formats are not necessarily compatible between old and new. So, if/when reverting back to an earlier NextGen version, this leftover “may” cause conflicts with the earlier version you reinstate.

There is a lot of “might” and “may”: the only way to know is by trying it out (on a development site first, preferably…).

Check whether the Theme loads a jQuery version. If it does, then there is a likely jQuery version conflict on your page, since NextGen loads the jQuery version bundled with WP.

Have you tried to follow this documentation?

Have not tried it myself, but following this, you should be able to customize the CSS.

Other option is to create your own display type, but I have just done that, it is not for the faint-hearted!

You are welcome. I learned something as well!

Do you have a call to wp_footer in your page template? Debugging NextGen, it seems that the enqueuing of the lightbox libraries is done from the wp_footer action hook.

Just to be clear, you are not trying to enqueue/register the lightbox scripts yourself from your theme, right?

There does not seem to be any version of the lightbox jQuery plugin loaded.

At the very least, I believe that jquery.lightbox-0.5.min.js should get loaded. Probably nextgen_lightbox_init.js should also get loaded. All the resources required by Lightbox with NextGen should be found under wp/content/plugins/nextgen-gallery/products/photocrati_nextgen/modules/lightbox/static.

NextGen should load them when you select Lightbox, why it is not there, don’t know.

Check this post.

According to Photocrati, you should not lose your galleries, since NextGen does not delete its own data when uninstalled/deactivated.

Strong recommendation, however, to backup your site before uninstalling/reinstalling.

Have you checked if there is only one jQuery version being loaded? Sometimes, the problem is caused by two versions of jQuery being loaded on the same page (or two versions of the Lightbox library).

NextGen Gallery does load jQuery, it loads the one bundled with WP. What I have seen is that quite a few Themes load their own jQuery version. So, when NextGen kicks in, two conflicting versions of jQuery exist, and confusion follows for the JavaScript engine (which version of a function to take).

Happened to me a year ago, took me 3 days to figure out what the problem was.

@larrynorton – Might be a jQuery version conflict issue: two versions of the jQuery library are loaded concurrently on the Gallery page: https://www.kathyeyster.com/wp-content/javascript/jquery.min.js loads version 1.2.6 of jQuery, then version 1.10.2 is loaded as part of nextgen: https://www.kathyeyster.com/wp-includes/js/jquery/jquery.js?ver=1.10.2

Try removing one of the two jQuery versions (if possible, stick to the one bundled with WP, ie, the one loaded by NextGen).