Mike Rockett

@owzim - It's a third-party parser that I chose as it has automatic delimiter detection. I read somewhere that str_getcsv is not RFC-compliant, but more importantly, it doesn't escape quotes correctly. That said, I might look into it and see what workarounds are worth the switch. Regarding your issue, I'll need to look into it further - I don't know where those dates are even coming from, or why it's even trying to set dates at all (in the first instance); it could be something to do with the SQL defaults. What version of MySQL are you using?

@tpr - Jumplinks 2 will be able to export all of its data, including config, via JSON or a gzipped archive containing JSON data. It will also be able to import from CSV and JSON files generated by other systems. When importing from JSON, a specific format will be required, but the importer will ask for fieldnames where they don't match the destination fieldnames. So If you provide {{"from": "/Somedir/file.ext", "to": "/awesome/path"}}, it will work correctly without asking questions, but if from or to or any other field does not use those names, then the importer will ask what the names are so it can read those instead. ---- @All - Initially, I wanted to have the PHP version requirement match that of Processwire, but I would now like to stick to the PW version recommendation, which is currently 5.5+. This allows me to use slightly newer components. However, 5.5 is at end of life, and only 5.6+ is currently supported. In the interests of users with hosting providers who still offer 5.5 as the newest version, Jumplinks will work for you. That said, using a host that provides unsupported software is not recommended. Many providers are moving over to 7.0 and 7.1, so the Jumplinks PHP version requirement become 5.6 when 7.0 active support comes to an end in 10 months. Then I'll follow that format in the future, meaning that 7.0 will be required when 7.1 active support comes to an end in 1 year and 10 months. It's either that or I run a poll to see what version of PHP folks are using, and then make a decision from there. For those interested: http://php.net/supported-versions.php

Bumped to 1.5.47. Important update for anyone needing CSV. Though it doesn't look like anyone has used it since January last year ? Thanks again @owzim!

Thanks for spotting that @owzim; looks like an essential line in the importer mysteriously vanished (in this commit that's a year old; only spotted now). More than likely a mistake on my side, but I do remember phpfmt was playing up at some point. Anyways, adding the line back - will bump shortly.

Loving my host so much -- they automatically enabled LetsEncrypt for every single one of their clients on shared and reseller hosting with automated renewals. Interesting thing is that they didn't announce it or place a readme in the skeleton directory for new accounts. Nonetheless, it's there, and it works really well. All I have to do is force HTTPS. ??

Have been doing some work on v2, Currently, the new manager looks like this the image below. Descriptions: I've opted to show the optional descriptions underneath the source, and there will also be an option to not show them if it starts looking too cluttered. Originally, I'd said that they should be shown to the side of the source, but that makes it difficult and tedious to prevent datatables from running of the side of the page. With that said, my recommendation is to only use descriptions where they are really necessary -- like if you need to use the description for the purposes of searching a large data-set and you can't remember the source. At the end of the day, this feature won't be used my many and, for those who don't use it, it won't get in your way. Parameter Highlighting: You'll also notice that parameters in the jumplink destinations are now highlighted - this makes it easy for those who don't know 100% what's going on (like someone who has taken over a site) to learn quickly (tooltips provided). This feature can be disabled, though I'm not sure if it should be disabled by default. Please vote in reply -- if there's no feedback, I'll leave it enabled by default. Lastly, I don't think it's necessary to highlight source parameters (too flashy), but I do plan to add a slight underline to those for the purposes of tooltips, which will only really be handy for aliases such as segment. Slug alias: Speaking of aliases, I've added a slug alias, which strictly captures parts of a URI that are slugs; that is, a word, optionally followed by a single hyphen, rinse, repeat. Segment, however, is not strict and allows any amount of consecutive hyphens. In the new documentation, I'll recommend the use of slug.

I can be guilty of the same, hehe! You're welcome.

@owzim - This is what destination selectors are for. In your case: source: project?id={id} dest: [[parent=/projects/, oldID={id}]] Anything inside double-square-brackets is a selector, and returns the full httpUrl of the page. You can also append a query string to the destination for the purposes of analytics, if you wish. (The syntax is changing in v2 to @[selector].)

@owzim - Thanks. Jumplinks v1 doesn't support explicit optional trailing parts, so you'll need to create a separate jumplink for now if you want to capture foo=bar. However, if it doesn't matter what needs to trail the first parameter, then you can simply use project?id={id}{all} and leave the destination as-is. v2 will support this. You'll be able to wrap the optional part in square brackets and Jumplinks will add the optional part to the end of the destination if it appears in the source, and it'll also ensure the URL is structured properly. In other words, you'll be able to set it up like this: Source: project?id={id}[&foo=bar] Request: project?id=4 --> project/project-name Request: project?id=4&foo=bar --> project/project-name?foo=bar If the source is project?id={id}[!&foo=bar], however, then the optional part will not be added to the destination. I haven't actually worked on the feature yet, so it may change; but this is how I plan on doing it. (Speaking of which, forgot to add this to the roadmap!)

@gebeer - Works perfectly.

@gebeer - I would be inclined to make that compatible with namespaces being on the third line as well - not everyone keeps it right at the top next to the open-tag.

Have pushed a fix; please update to 1.5.46 and let me know if it works.

Unfortunately, I'm not able to determine why the httpUrl is being appended to the root URL. I'll need to look into this further, but it has something to do with preg_replace_callback which is at fault here. The method in question is supposed iterate through each source wildcard, applying any replacements to the destination. But as their are no wildcards in the destination, it should be changing anything. When you supply / as your destination, Jumplinks converts this to page:1 so it can get the full URL to that page. As it loops over the source, it's somehow adding that URL twice to the destination. I need to head out now, but will be back in a bit to investigate. I do know that Jumplinks 2 is not succeptible to this as it uses a completely different method, powered by FastRoute. I'll try to continue work on that Jumplinks 2 today. (To everyone who's been waiting in anticipation for it, I'm so sorry it's taken so long.)

Looks like a genuine bug fell in here somewhere - all redirects with Page IDs appear to be broken on my side. Investigating now.

I see - this should definitely be possible (using {all}) and page:1 or a relative/absolute link to your domain root. I will take a look at this when I'm back from work this afternoon.

Would you murder me if I told you I was doing this via CSS on my blog? ? I'm sure I searched for this, but couldn't find what I was looking for - gonna try this out.

Of course, this is not a bug - but look what happens when you use an edit link in the front end. Wash, rinse, repeat.

In response to Teppo's Weekly #139: Thanks for the features; much appreciated! For the most part, web typography is kinda new to me. I've noticed in the past, but never really thought much about it (most people don't). So playing around with all of this is quite interesting. There is still much for me to learn in terms of best practice, and I want to see where Typeset can be improved. Whilst I really like PHP Typography (specifically the fork of it found in wp-Typography), I'd like to be able to use Typeset as a daily driver once performance has been improved as much as possible. Also, just a note about the typography textformatter: it's only slow when hyphenation is enabled; that appears to be the case from experiencing the difference on my blog. Nonetheless, it's always recommended to cache your output for better performance. No amount of performance-improvements to the modules will save the time that caching will.

So the current maintainer of wp-Typography and I have been having a discussion about performance, and I've since done some benchmarking. It appears that Typeset is actually slower, but it is due to two modules: small caps and hanging punctuation. These two modules appear to be very resource intensive. I think Typeset felt faster because they were being used in different contexts - one with ProcessWire and one without (Typeset doesn't have a text-formatter yet). If you're interested, here's the discussion (benchmarks included).

In light of the above, I've been working on a port of Typset from JS to PHP: https://github.com/mikerockett/php-typeset It doesn't include hyphenation, but does add features not found in the original JS version. It's currently in alpha, and I'll make a Textformatter for it when it's stable. I haven't done benchmarking between Typography and Typeset, but I can already feel that Typeset is faster. Sensible (common) defaults are set. If you're keen to have a look, please let me know what you think. ?

Important: The behind-the-scenes library can be quite resource heavy. As mentioned in the module's configuration, it's highly recommended that you cache your templates or use ProCache. Users of the WordPress plugin are also advised to use Super Cache, and so there's not much I can do about this.

Bumped to 0.2.0-beta: Switch from the old PHP Typography library to the newer, more frequently updated library found at wp-Typography. This adds several features that are now being used in the module. Some features are not working correctly for me, and so I have excluded them. Soon, I'll do a complete tear-down to see what works and what doesn't. Config no longer allows the textformatter to be disabled. If you want to turn it off, rather remove it from your field. Config no longer allows to reset to defaults. A different implementation of this may be added in the future, if deemed required. Stylesheet is no longer provided as a function for the purposes of not being opinionated. There is, however, a stylesheet in the module's directory, which can be used as a basis for your main stylesheet. You will also notice that the stylesheet references new classes. Due to the fact that this fork of PHP-Typography uses hanging punctuation, new classes have been added. However, they retained the original naming for single and double initial quotes. As this is a new module for PW, I thought it sensible to change these names. All the new class names are in the stylesheet, and also in the Typographer subclass.

@owzim - You're most welcome. Yeah, I think those who write markdown should be able to configure the output, making it somewhat less opinionated. Hadn't actually seen your module - surely the core textformatter would have rendered yours redundant?

As I mentioned in this issue, I've create a new textformatter for ParsedownExtraPlugin, which adds some oomph to your markdown. Repo: Parsedown Extra Plugin Unlike the built-in textformatter for Parsedown and Parsedown Extra, this should be used when you want to use Extra with additional configuration/customisation. Some examples: ### Test {.heading} - A [external link](https://google.com/){.google} with `google` as a class that opens in a new tab if the config property is set. - [Another link](/page){target=_blank} that opens in a new tab even though it isn't external. ```html .html <p>Test</p> ``` There's some config options available to you, such as setting attributes on all/external images and links, setting table and table-cell alignment classes, adjusting footnote classes and IDs, adding <code> attributes to their parent <pre> elements, and changing the <code> class if your syntax highlighter does not use language-*. I was thinking about adding the ability to make links open in a new tab by appending a plus to the link syntax, but only external links should be opening in a new tab anyway. Further, this would add extra, unnecessary processing time. Please let me know if you bump into any problems. ☺️

Yeah, I'm using the good ol TemplateTwigReplace.