Mike Rockett

I'm running Windows with the latest Chrome & Firefox - scrolling with the mouse-wheel and the trackpad is slow. Scrolling by touch is also slow, meaning that it doesn't continue and then decelerate when I let go. Perhaps this might be applicable? Also, it appears that I can't scroll by touch on Firefox - not sure if this is a jScrollPane issue, or its implementation. (I doubt it's the latter.)

Great site indeed. Only one issue: scrolling with the wheel is very slow...

Great work Tom - just installed the latest dev and played around. Very happy with the outcome. Menu flyouts are hovering over the top nav - is that intended?

Someone, give that man a Bells! Can't wait to see it - clients shall be happy.

Great stuff indeed! Really fantastic to see big brands using PW.

I can confirm, it work exactly as intended. Running my own intranet site on LiteSpeed.

Tom, I believe you have the ability to read my mind. How did you do that? Can't wait for these updates, simply superb!

It appears that this is now happening on another site as well. If I try to update a module, the browser navigates to admin/module/download/ and the home page is displayed. Request Header: POST /admin/module/download/ HTTP/1.1 Host: <redacted> Connection: keep-alive Content-Length: 103 Pragma: no-cache Cache-Control: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Origin: http://<redacted> User-Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2358.0 Safari/537.36 Content-Type: application/x-www-form-urlencoded DNT: 1 Referer: http://<redacted>/admin/module/?update=VersionControl Accept-Encoding: gzip, deflate Accept-Language: en-GB,en-US;q=0.8,en;q=0.6 Cookie: WireTabs=tab_new_modules; modules_section1=; modules_section2=; modules_section3=; modules_section4=; wire=3ddcf3e516910183700aed4d8dd7d5e8; wire_challenge=lKTmEV1SH83NgceBpBytCpSOUKuitA8Q Response Header: HTTP/1.1 404 Page Not Found Date: Wed, 24 Jun 2015 14:10:52 GMT Server: Apache Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache X-Frame-Options: SAMEORIGIN Vary: Accept-Encoding,User-Agent Content-Encoding: gzip X-XSS-Protection: 1; mode=block Content-Length: 1868 Keep-Alive: timeout=5, max=95 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 What could be causing this? It's really so unusual...

Ah, that is indeed a bad assumption on my part. Because the REQUEST_URI in this case is for the root, PW will not return a 404, and thus Jumplinks won't come into effect. Unfortunately, this is the caveat of hooking to the 404 event. I will look into this when I rewrite the module. As a suggestion, and if you're using mapping collections, you can add the following to your condition and rule to .htaccess (right at the beginning to be safe): RewriteCond %{QUERY_STRING} ^p=(\d+)$ RewriteRule ^$ /postid_querystring?p=%1 [R=302,L] Then you can create a jumplink with postid_querystring?p={id} as the source. (Not tested, but it should work.)

I've encountered this a few times before, but not recently. I'm sure it has something to do with DirectWrite as I've also seen it happen on other sites, such as winsupersite.com.

In my honest opinion, I believe it's better to stick to the rules in place - they're all there for a reason. That said, you could add a condition to check for an applicable sub-folder. I don't particularly like making changes to the htaccess file as future ProcessWire upgrades can overwrite them. Sure, that's no biggie as your custom stuff can be added again from the backup file. However, it's just unnecessary work. I haven't really looked at what gets blocked and what doesn't, but you might be better off creating a site/views folder, which is more applicable to the purpose.

It's a method I'm currently using to allow users to create jumplinks that start with index.php. Not sure why Google is indexing those, especially considering they are 404s. If you have a jumplink that checks for index.php?cat=32, for example, but you make a request for anything but the 32 and leave the index.php in the URI, Jumplinks will redirect index.php to index.php.pwpj so that it can be tested. I will more than likely be using a better method when I rewrite the module. I could indeed do that, but I think it would be better for that to be handled with .htaccess, like so: RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} \.(jpg|png|gif)$ RewriteRule ^ - [G,L] Check the request doesn't match an existing file Check that an image is being requested Send 410 Gone if both conditions match

Just a heads-up: As mentioned, lot's on the plate these days. But I've made a decision regarding the module going forward. When the next one or two PW minor stables come out, I'm going to start making Jumplinks 2.6-only. Lots of goodies I want to use, and as stated earlier in this thread, Jumplinks is mostly for new sites resulting from migrations. Of course, Jumplinks won't upgrade for anyone using it on 2.5.3. Also, and because of this decision, I'll be switching over to some kind of autoload solution so I can split up logic etc. It's essentially going to be a rewrite. Nonetheless, it will function exactly the same, sans the 404 Monitor, which I'll try to release at the same time. Speaking of the 404 monitor, I've already drawn out some blueprints and flow charts - ideas have come to mind, and I think it's going to be a really helpful module. As said, it will mesh well with Jumplinks. Edit: Okay, I see that 2.6.1 is already on stable (of course, it should be). I'll need some time before I start this up.

Unfortunately not - it isn't something that happens often, and so it isn't a feature. It might be best for you to use .htaccess for that. I will be rebuilding the 404 Monitor as a separate module, and may include that. That's also on the to do list. Originally, I skipped the validation as I found it was not a common occurrence. But, I do believe that some kind of validation should be put in place. I do have quite a lot of work at the moment, and so cannot commit to actually getting these things done. Thanks for your suggestions!

Could it be worded any better? Perhaps not. Thanks for sharing.

After some thought: I'm a little undecided as to how much functionality I would want in this monitor. Currently, Jumplinks serves its purpose, and adding to much to it might not be the greatest idea. That said, I would be prepared to release a separate 404 monitor module that includes this functionality. Firstly, Jumplinks would be able to tie into this module if it exists. Secondly, I'd be able to add certain security features to it without bloating Jumplinks. Preferably, I'd want to implement this module in such a way that it modifies the .htaccess file in the following way: when browsing the log, a user with the relevant permissions would be able to blacklist a certain URI for a fixed/indefinite period of time. They'd also be able to block an IP (based on the findings in the log) for a certain/indefinite amount of time. When these 'blocks' are defined/modified, they'd be added to the .htaccess file, and the module would periodically check (lazy-cron-like, say twice a day) to see if the file is up to date. An example would look like this: #< BEGIN ModuleName <last-check: <time>> Redirect 410 /wp-admin # always Redirect 410 /etc # <time>-<time> Redirect 410 /etc.php <time>-<time> Require all granted Require not ip xxx.xxx.xxx.xxx # <time>-<time> Require not ip xxx.xxx.xxx.xxy # always #> END ModuleName For me, this is a performance thing - i.e. booting up the whole PW system just to block/limit access is unnecessary. With the above in mind, this may land up becoming an .htaccess security-driven module, similar to those made for WP (the bain of my existence); however, it would only include essentials. (It would more than likely not be called '404Monitor'.) As said, the added benefit would be that the module can provide a 'safe' list of 404s from which Jumplinks can derive it's data. Thoughts?

I'm just wondering if I should maybe integrate the monitor with the new 404 logger by kixe. What do you think? Scratch that. Unfortunately, the logger doesn't capture as much information as I'd like to show. An SQLite-base solution will be better. Edit: Perhaps a separate module, included in the package, will be best. Let me think on this.

Interestingly, I bumped into this issue yesterday on a live site - thanks for bringing it up. Initially, I just implemented it as-is due to the fact that it can be useful in most cases. That said, these kinds of attacks are becoming quite regular these days, and so I think it's a very good idea. Thank you, I'd very much appreciate a wrapper class, which, in my opinion, is much better than using a log file. When I have some time - hopefully soon - I'll upgrade the monitor.

Just as a follow-up to the shortlinks tutorial posted yesterday: Jumplinks can also come in handy if you want to redirect ID-based URIs. This is a result of the Destination Selectors feature I added a while back, thanks to the suggestion by Macrura. The Process: Let's say you have a Journal located in the root of your page tree, named journal. Each journal entry is assigned to the journal-entry template If you want to redirect ID-based URIs to their named equivalents, create a new jumplink like so: Source: journal/{id} Destination: [[template=journal-entry,id={id}]] So, when requesting /journal/1078, for example, you'll be redirected accordingly to /journal/hello-world/. Of course, you could take this further, but this is just a basic idea. Might be handy for someone using Jumplinks.

Ah, of course. Switching to prev fixes it. Interesting how it worked before...

Interestingly enough, I'm getting the same error (in 2.6.0), and I'm not even making use of the comments module... Edit: My bad, I see I do have a comments field in the template in question. That said, I don't recall adding it. But that could be my terrible memory. Edit 2: Nope, looks like Comments and Categories was added when I upgraded to 2.6.0. Why would that happen? (This could be an error on my part, where I may have experimented with the comments module, but I really don't remember doing it because I specifically said to myself that this site doesn't need comments...)

I think I may have stumbled into a bug, or perhaps something has changed since 2.5.3. I have the following function that I refer to in order to obtain the latest journal entry, or the one after that if the latest is currently being viewed: function journalLatestEntry($showNextIfCurrent = true) { global $wire; $return = array( 'page' => $wire->pages->findOne('template=journal-entry, sort=-created'), 'isCurrent' => false ); if ($showNextIfCurrent) { if ($wire->page->id == $return['page']->id) { $return['page'] = $return['page']->next; $return['isCurrent'] = true; } } return $return; } Unfortunately, since upgrading the dev-site to 2.6.0, next is returning NullPage erroneously as there are pages after the one returned. Perhaps something has changed with regards to the way in which findOne() works?

Great to see all the new additions, as well as the microsite - superb work!

Also getting that error 19 - download corrupt. I'm on shared hosting - guess I'll have to speak to my host? (Interestingly enough, I'm on a new shared server, and the load isn't very high...)

So my host doesn't know what's going on, and I have done a fresh install, the same way I do it for my other sites with the same host. The only way I could update modules was by going to New and entering the class name. Side note: Also been having issues today trying to upgrade a site to 2.6, and it seems the server that the site lives on is quite popular, and so the download breaks. Definitely thinking about changing hosts.