Mike Rockett

Hi @kater, you're most welcome. A plain query string request to the root of the site won't get caught by Jumplinks. You would be better off using htaccess to convert these to request URIs and then having Jumplinks process them. RewriteEngine on # These should go directly after the above RewriteCond %{QUERY_STRING} ^q=(.+)$ [NC] RewriteRule ^$ /%1 [R,L] (Haven't actually tested it, but it should redirect /?q=something/else to /something/else with a 302 status code.) Then omit ?q= from the source.

(Copied from comments section - better to discuss this here.) I really like the new approaches being taken here - big steps for ProcessWire. However, the first thing I noticed was the fact that I can easily have three page trees in a single view, using the left sidebar, the root admin page, and the right sidebar. I get how the additional access-points to the page tree are useful, but perhaps they should only become accessible as and when needed? So when on the root admin page, I should not be able to access the sidebar page trees. Though, I'm sure you're already aware of this and have a plan in motion... Just pointing it out because of how it jumped at me. I also think the left sidebar should not be able to grow in size more than it needs to. Not sure what thresholds should be put in place, also giving consideration to mobile behaviour, but maybe 50% of the page width should be the limit. From the Chrome side of things, all looks good here, except for the fact that "Uncaught TypeError: Cannot read property '_wrapper' of undefined" is thrown when clicking on an item in the left sidebar.

@theoretic - Thank you for spending some time on this. Whether or not a logo decision has been made (which it has), it is great to see folks interested in the topic that are willing to contribute -- so thank you for that. There's also a thread regarding a new website, which I opened in January last year for the purposes of sharing design ideas: As mentioned by @LostKobrakai, Ryan will be spearheading this. With that said, please feel free to share any ideas you may have about the new site on that thread. (The two threads mentioned herein are the ones we should focus on to keep everything centralised.) Thanks again for your input.

@peterfoeng - I'm not sure about Latte (tpr might be able to answer this better), but surely you can have one layout extend another? So you would have a base layout and a sidebar layout where the sidebar layout extends the base layout, which would import the content of the sidebar layout if it's provided. Blade provides a nice way of doing this by using a combination of @section() and @parent.

Hi Jeff - it's been a busy while for me, so dev is paused at this stage. Exporting will definitely be in v2, as well as a v1 to v2 migrator; no plans to add an exporter to v1. Hoping to get back into it soon, though I can already see the next few weeks being quite busy.

Ah, sorry about that. Thanks for moving.

More: http://gizmodo.com/cloudbleed-password-memory-leak-cloudflare-1792709635

I haven't tested this yet, but I think we should be using the View component (along with Blade, included) so that we're up to date with the features. The actual implementation by Matt relies on 5.1 components, but I doubt much has changed in terms of setting things up - should be easy enough, if anyone is interested. (I would, but no time.) https://github.com/mattstauffer/Torch/tree/master/components/view Nevermind: I see the third-party packages are importing Blade directly.

Sure, though I get the impression of material design as it seems to be popping up everywhere, which is why the association is made. I must say, though, the general impression of the docs site is 'material', but that's probably because of the colour they chose for the header -- so many administration framework themes are using colours similar to that. The use of depth could well grow on me, but I would probably opt for smaller shadows. Perhaps this can be explored further down the line.

I definitely like the per-field border-control. Can't say I'm a fan of the card view, but that's because material design (and derivatives thereof) has never been my thing. The colour-control on a per-field basis also looks quite nice. I wonder if you could also add the option to only set the border colour, so that the background remains white. Great to see a new admin 'framework' coming into the picture.

@d'Hinnisdaël - The htaccess ruleset doesn't allow spaces in URIs as ProcessWire doesn't use them. However, this can easily be modified. Open the htaccess file and go to rules 16a and 16b. The default installation uses 16a by default, and you should switch to 16b if you require UTF-8 URIs. At the beginning of each character class (inside the square brackets), add \s to allow spaces. So, if you are using 16a: RewriteCond %{REQUEST_URI} "^/~?[\s-_.a-zA-Z0-9/]*$" (This assumes you are using the latest versions of PW - that is, 2.8 or 3.0.) You can then just use normal spaces in your jumplinks, and they will be detected just fine, provided the correct wildcard type is used.

@Robin S - I'm using a local hosting company called Elitehost here in SA. They told me Let's Encrypt is built into their WHM/cPanel instances (v60) on all servers. My only gripe is with regards to subdomains. The LE system auto-issues certificates once per day, so I have to wait after having created a subdomain. If it's urgent, though, then someone on the support team will do it manually for me.

Maybe you could try a transactional API like Mailgun instead?

Are you receiving any errors or is the email simply not going through? Checked the logs?

Hehe, 404 replies! (Wonder why the topic tags are stretched out like that...) Anyways, for those of you who have not seen this yet, here's an update on progress. When v2 is ready for a release of any kind, I'll create a new thread for it. v1 will continue to be supported for those who still use PW 2.7- (for everyone using 2.8+, there will be no reason to stay on v1). v2 will have it's own repo (or perhaps I'll have v1 have it's own branch, and v2 will be dev/master -- maybe that's better).

I totally should have reviewed the FAQ:

@Macrura - thanks, and no stress. Will see what I can find in the meantime. As a side note, there is also Typeset, which I ported over from Typeset.js. However, there are a few bugs relating to the HTML parser, so there won't be a textformatter until such time as those are all ironed out.

@Macrura - Can I get links to the sites in question?

Thanks for the update - yeah, I figured it wouldn't have been easy to get the source. Anyways, I have opened up an issue over at wp-Typography (PHP Typography is maintained within that extension for WordPress). Hopefully we can find the culprit soon.

Sure, but one never knows - I would have liked it to. ;-) So that seems really odd. At first I thought it was the diacritics feature, but those mangled words don't have any diacritic alternates. It could perhaps by hyphenation, but my gut tells me it's not very likely. Nonetheless, try turning that off by removing the language code from the hyphenation field in config. Failing which, perhaps me seeing the compiled source code would help - I could then investigate myself or discuss with the author. Also, what font is that? Raleway?

Multisite and Jumplinks Can't remember if this was brought up before, but I think there may be a need to have Jumplinks v2 support Multisite. Besides there being two dev branches and referrals to how things can get messy, I think an implementation on the Jumplinks-side would be easy enough. Do you think it would be simple enough to have the jumplink editor list valid domains from config so the user can select which domain(s) the jumplink belong(s) to? Also, I'd be interested to know how many use the core multisite method (multiple site dirs sharing a single core) vs those who use this module, as I'd need a different method to obtain the valid domains for those using the core method. Lastly, is the current dev2 going to make it to master any time soon?

@Macrura - Thanks for bringing it up. Interesting that the fonts would look garbled - could you perhaps post a screenie of what that looks like? That aside, it's more than likely something I can't solve as it's unrelated to the textformatter itself, and more related to PHP Typography. However, I can't see how it would cause text to be garbled, so a screenie would help loads.

@owzim -- Sigh of relief from my side! You're welcome.

Bumped to 1.5.48: Now using League\Csv for CSV importing. Note that delimeters are no longer automatically detected, and you need to specify your delimeter and enclosure characters separately. Blank lines are now also ignored. @owzim - This might fix your issue as the importer now delegates the start and end times to the same method used for the main jumplink editor. If that works for you, then this will as well. If it doesn't fix the problem, then I'll need to investigate further. On my side, however, all looks good.

Interesting, when I use foo;bar, it translates uses that as the source and / as the destination, even though it has been set up to detect the delimiter. Anyways, I've never really liked that parser, so will switch to League\Csv shortly, especially since it will be used in v2. It could well fix the issue you have.