Mike Rockett

The way I see it, doing it that way won't trim much off as most of the time is dedicated to processing the JSON object anyway. The difference is negligible, and would delay the loading of the admin interface markup.

@Jason Huck and everyone else working with large datasets: I'm playing around with DataTables, and these are the initial benchmark results for 6000 jumplinks. Jumplinks Manager containing only page markup: Server Processing = ~430ms Receiving = ~120ms JSON AJAX request for DataTable: Server Processing = ~6320ms Receiving = ~110ms (reduced as there is no bulky table markup) Peak Memory = ~52MB (much better, also reduced to lack of table markup) Essentially, the loading time has been cut in half. However, this will be further improved the links for the table are being processed server-side via Eloquent accessors. I'm going to move that to client-side processing to cut down the load time even more. There is the option of server-side processing on a per-page basis, but I think that's overkill. I'm pretty new to datables, to be honest, and so not sure how to do a whole bunch of things. But I'm sure it'll be easy enough (readthedocs, hehe).

Datatables would indeed be my first option. There are others, and I'd ideally like to use one that has the required features and looks good in the admin UI without having to modify much (I would like to also try and retain the design I have above). I've done some quick, prelim benchmarking on 6000 jumplinks (generated by faker) in v2: Request → 404 (no hit): Server Processing = ~900ms; Receiving = 0.1ms Loading Jumplinks table: Server Processing = ~2900ms; Receiving = ~9900ms (memory limit increased to 512MB as it exceeded the default 128MB) This was done on my laptop dev machine - a 4th-gen Core i7 running PHP 7.0.9. So it seems all the pre-processing going on in JL2 really doesn't use much at all, and FastRoute makes things much faster by combining all the jumplinks into a single regex for matching and dispatching to the post-processing handler. 900ms (half of that, actually, due to the loading of PW) to scan through 6000 jumplinks is really awesome! All-in-all, it looks like the only issue is the front-end, which is expected for larger datasets. Given that you say there is no logical structure that could minimise your jumplinks down drastically enough to improve performance, I'm going to go ahead and migrate to Datatables (or something else that may be more suitable; I have seen a few, but can't remember what they are called).

Very nice. However, I think the menu/masthead should always be fixed to the top. When I scroll, it fades down into view after the initial one scrolled up with the page... Better UX would be to keep it sticky always.

That seems strange - it really shouldn't take so long at all... If it is indeed Jumplinks that is causing that delay, v2 of the module will more than likely solve it. Actually, I take that back - the handler would slow things down. That said, JL2 will speed things up. This was never benchmarked in v1, so I believe you on this one. Perhaps some pagination is in order then... Or perhaps I should switch over to an AJAX-driven table ith filtering...?

@Jason Huck - Magic, glad you got it sorted.

@Jason Huck - did you manage to see what the issue may be?

@Peter Knight - Hi Peter. There's no limit on that front. Current module shows all of them on the single page. At the time, I thought to myself that if jumplinks are used effectively, then pagination won't even be needed. Doing the same thing for JL2.

For me, it follows a principal called 'separation of concerns'. Running analytics has nothing to do with the actual running of your site, and so it should be kept separate, on another domain (or subdomain, which is technically another domain). So my recommendation is the same - move PW site to the public root and move analytics to a subdomain public root.

@mrjasongorman - yes, elabx created a temp redirect while this gets sorted out. Before it was showing the site without a redirect.

I see - it is showing on whois.com as WHOISGUARD.

Sure, but that information should still be visible, right?

I just did a WHOIS on that copy-cat domain. Why is there no registrant info? Edit: And it appears that site is meant to have its own site.

That's the problem right there - the request should not be http404, which is the built in 404 page. That should show the original request. As it isn't doing that, it means that something is redirecting to the 404 page before Jumplinks can do its thing. Perhaps there's another module hooking to the 404 event in play? Template code, maybe?

Hi jason - not sure what the issue could be there. Could you perhaps share the debug log (PM is also fine, if you'd prefer that)?

First time I've seen this thread. I still find it odd that the virtual host setup is allowing this kind of thing to happen... In fact, it's the first time I'm hearing of an issue like this in the first place. Could this be a service-provider issue - possible server misconfig?

Make sure the user has the necessary privileges on the database.

@szabesz - It is intentional, as it was in JL1. However, I am open to bulk operations. My idea is to perhaps incorporate this into the ordering utility. The new manager page will paginate jumplinks to show a certain amount per page. As there will be times when certain jumplinks would conflict, order is important. As such, I'm thinking about putting together a utility to re-order jumplinks. Whilst there, bulk activities can also be performed. I'd like to maybe do it there so as to not clutter up the manager page - my objective is to keep things simple and neat, and not to clutter up the interface. It has been brought up before that the module remain easy to use with no feature overload, and so I'd like to keep it that way. As such, whenever something new is added, it is disabled by default. Ordering/bulk actions won't be disabled by default, but everything else that can be classified as an 'additional feature' will be. I've also decided to turn off Collections and Page Selectors by default as these features are classified as 'additional' due to the fact that they are not required for the module to operate. The hit logger is also disabled by default, along with destination validation.

Thoughts on the new manager page?

Not sure I'm following the exact requirement here, but AdminThemeReno is responsive on mobile, and accessing these features is pretty easy via a tap on the applicable item in the page tree...

For those needing to temporarily disable the module, I've added the ability to do so in 1.5.43.

Master branch bumped to 1.5.42 in response to #15: If you need to disable a jumplink, simply add !! to the front of the Source. As you can see in the previous post, there's a better way of handling this in v2.

State toggling is done in v2 - already shared in this issue.

Great stuff, Ryan - nice to see ProcessWire in an organisation! I wish GitHub had a "copy repo" tool so that issues could go along with it... That said, it really is nice to see zero issues.

Okay no, I think I'm going to skip this. Will use a subtle animation in the row to show that the state has changed.