Mike Rockett

@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.

@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.