Mike Rockett

@Kiwi Chris - great, working fine now. Re: css: Yeah, I'd keep it in the head and perhaps gzip it (you're already using aiom, so most of the work is done already).

Glad to know Jumplinks came to the rescue here (and that you used selectors), however it doesn't appear to work as index.mvc is still on the server. So if I request /index.mvc?article=6, it attempts to download the mvc file instead of redirecting. I'd also recommend moving the CSS reference up to the head to avoid the FOUC.

Finally: http://www.underconsideration.com/brandnew/archives/new_logo_for_patreon.php

You're welcome. I can do that, considering that it is already implemented. It's a workaround that I'm not particularly fond of though (from a namespace point of view). I'll keep it in until an alpha release, at which point maybe someone has a better alternative that can be used instead - so we can take it from there. Are you using the legacy branch?

Small update

Agreed - you can take the MVC approach using template-files. If you really wanted to use a router like that, you could always create a Process module to use as a fallback to non-existing routes. Jumplinks 2 will use this methodology on the 404 event, where it collects routes from the database and applies a single action. You could do something similar where the module sets up the router (in the case of Jumplinks 2, it is FastRoute), and then have it include a routing file. From there, you'd have access to the global scope and do pretty much whatever you want to do.

Yeah, I tend to stick to the tree-model for this kind of thing. In this case, I tend to use "legal/terms", etc. If need be, there's always Jumplinks for quick redirects.

Yeah, looks like it's a VirtueMart site.

I just tried to check, and the response headers indicate that the server is running nginx. Did you change it? It doesn't show a PHP header though.

If you need extra customisation, try out ParsedownExtraPlugin.

Right - untested code, based on a theory trying to avoid two jumps. Wish servers made this easier.

Lol at the admin path - opensesame! Brilliant

I would say that each rule should force both scenarios: # Force www and HTTPS RewriteCond %{HTTP_HOST} !^$ RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=302,L] # AND force HTTPS and www RewriteCond %{HTTPS} !on RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=302,L] Remember to change 302 to 301 when done testing.

I'm so sorry - wasn't thinking when I wrote that... My apologies. @gurkendoktor is correct though... I'm not sure how the system works with PW, but it should desregard old cookies, no?

Surely you mean cache?

Hi, and welcome to the forum. We do have wireshell, which can be used to install modules from the directory by class name. As for Composer, I think that the module would specifically need to support it - widespread implementation hasn't been done as yet, but I'm sure we'll get there in the future. There is a third-party installer for those modules that do support it. Hope that helps.

Correct, they're hosted with Ryan. DNS Dumpster reports the IP of IBM SoftLayer, but they only update their records every now and then so it's safe to assume those are now hosted with Ryan on Amazon.

I don't think those sites will last very long - very likely to be taken down once the new site is up.

Just a note about CI: I believe that the next version (4?) will be quite different to the current version, but will be familiar enough for those familiar with CI. Laravel is quite easy to learn, but I would suggest taking a course on PHP so you use a framework well.

At the moment, I'm on Win10, using ST3 and scoop for pretty much everything dev-related. Looking to switch to the next iteration of Ubuntu, which I hear is dropping Unity in favour of Gnome. I can imagine it'll be quite the change, especially with tools exclusive to Windows, such as Adobe CC. (so I'd have to use wine or a VM for that). Guess I'll miss WIndows incredibly as I'm so used to it, but change is as good as a holiday, as they say, and I'm in serious need of a holiday (or ten, consecutively). As for why I'm going to land up going this route: Windows is starting this whole SaaS paradigm, which I'm seriously not into at all. If I did land up getting into it, I'd probably only do it for the unix part of Windows. That said, better to develop on Linux as most servers are linux-based and, with Windows, you can ignore a whole host of things that don't make any difference (you know, like permissions, paths, etc). Side note: Office 2016 feels like a joke to me. Much buggier than 2013. However, I really like Exchange, but I'm sure there are good Linux clients that could handle Exchange pretty well (there's also OWA, which is actually pretty good for my needs).

Hi TheoTop, and welcome to ProcessWire. The methodologies and philosophies of CI and PW are considerably different. When it comes to MVC (or other similar chain), I prefer to use Laravel - but PW can easily handle most things quite well (especially in terms of information storage with relations etc). With that said, I recommend you have a look at the various courses available online to better your skills before you start choosing between frameworks and systems. TutsPlus, Coursera, Khan Academy, just to name a few. When you've done that, grasping Laravel/CI/PW/etc will be much easier, and you would be able to easily draw your own conclusions and choose the right framework for whatever task you have on hand. For payments, I think these are the go-to PW modules https://github.com/apeisa/PaymentStripe/ and https://github.com/apeisa/PaymentPaypal/. If you're looking to de e-commerce, try out https://www.padloper.pw/ (I haven't used it myself, but it looks perfect for the task - others can comment in on that). Best, Mike

Great stuff, Ryan! In SA, I've actually picked up a considerable speed improvement, especially on the forums. Not sure if that difference would affect you or Europe as much as it does here. Very snappy.

What a great site! Love seeing new design methods - this really is great!

Hi All, I know I've been distant, but work has kept creeping up on me and I simply haven't been able to commit time to continue work on Jumplinks 2. At this stage, it's difficult to tell when I'll be able to continue, but I do hope it will be soon as I'd like to deprecate v1 as v2 is already so much better. Again, truly sorry for the delays...

@kater - Yeah, I thought I'd said it before, just wasn't going to go find it. Thanks for pointing that out. I might find a way to resolve this with v2 (when I get back into its development). I could probably use an early hook (instead of the pageNotFound hook) for jumplinks that require it. Just a thought from the top of my head.