Jump to content

Recommended Posts

Moar updates: Finished working on named types for parameters, which was the base param-type before ({name:type}). As you can see below, we're testing with {fileext:ext} which converts to the regex format for FastRoute to handle:

Request URI: string(12) "AboutUs.html"

Matched Jumplink Object: object(stdClass)#5 (4) {
  ["from"]=>
  string(113) "{page}.{fileext:aspx|asp|cfm|cgi|fcgi|dll|html|htm|shtml|shtm|jhtml|phtml|xhtm|xhtml|rbml|jspx|jsp|phps|php4|php}"
  ["to"]=>
  string(7) "{page}/"
  ["deepClean"]=>
  bool(true)
  ["origFrom"]=>
  string(20) "{page}.{fileext:ext}"
}

Captured Parameters: array(2) {
  ["page"]=>
  string(7) "AboutUs"
  ["fileext"]=>
  string(4) "html"
}

Parameter 'page' cleaned (deep = yes) from 'AboutUs' to 'about-us'

Compiled Destination: string(9) "about-us/"

Also notice the deepClean property of the Jumplink object: Instead of setting the old Enhanced Wildcard Cleaning in settings, this is now done on a per-jumplink basis (defaults to false).

Going to start working on aliasing (aka old smart wildcards) now. Aliases will convert, for example, {id} to {id:\d+}.

  • Like 2

Share this post


Link to post
Share on other sites

Aliasing is done now. As you can see from the "fromLog" (which logs changes to the "from" property), the original "from" contains a mix of a expression-based parameter and an aliased parameter, which then gets expanded to include the applicable parameter type, and then finally converted to the FastRoute-compatible regex.

Originally, I wanted to have aliases convert directly to the regex equivalents, but we convert from parameter types to their regex equivalents anyway, so no need to add an extra step.

I think I have everything sorted now - just need to start moving this into a freshly-baked module. Hopefully I can release a beta in the next week.

Edit: Completely forgot about destination selectors (even though I can only really implement these in the module itself). I'd thought about re-conceptualising these, but something tells me the current implementation is fine. Only thing worth considering for me is changing from double-parenthises to single.

Multi-language (feedback needed, please): I'd love some insight from those familiar with multi-lang setups on how I could possibly go about incorporating awareness into the module. The problem I see is that each multi-lang setup is different, and so it's impractical to implement a solution that only caters for one group of people, and I also think it's impractical to have too many solutions and bloat up the module. As such, feedback from anyone who has experience with the different kinds of multi-lang setups on how I could go about this would be most-appreciated. :)

(Sorry for all the test logs - just showing that it works in case there are any concerns/suggestions.)

Request URI: string(44) "blog/post.php?id=882991&title=This_is_a_test"

Matched Jumplink Object: object(stdClass)#2 (4) {
  ["from"]=>
  string(47) "blog/post.php?id={id:\d+}&title={title:[\w_-]+}"
  ["to"]=>
  string(26) "post/{title}/?ref=post.php"
  ["deepClean"]=>
  bool(false)
  ["fromLog"]=>
  array(3) {
    ["original"]=>
    string(39) "blog/post.php?id={id:\d+}&title={title}"
    ["alias_expansion"]=>
    string(47) "blog/post.php?id={id:\d+}&title={title:segment}"
    ["regex_conversion"]=>
    string(47) "blog/post.php?id={id:\d+}&title={title:[\w_-]+}"
  }
}

Captured Parameters: array(2) {
  ["id"]=>
  string(6) "882991"
  ["title"]=>
  string(14) "This_is_a_test"
}

Parameter 'title' cleaned (deep = no) from 'This_is_a_test' to 'this-is-a-test'

Compiled Destination: string(33) "post/this-is-a-test/?ref=post.php"

 

  • Like 2

Share this post


Link to post
Share on other sites

Right, so I've made a few more developments to my test-phase, and am now ready to begin porting this to a fresh module setup, which is going to be based on something I'd setup a while ago. I intend for it to run in namespaces (Jumplinks\Something\Etc) and use traits. It'll also make use of its own autoloader.

Now, I'm not sure if using my own autoloader is the correct approach. I see that both 2.8 and 3.0 have Composer support, but not sure on the Composer-based differences between the two - could someone enlighten me on that?

Also, I assume I can work on the module in 2.8 only and it will be fine in 3.0? The only difference is the fact that 2.8 doesn't use the ProcessWire namespace, right?

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, Mike Rockett said:

Now, I'm not sure if using my own autoloader is the correct approach. I see that both 2.8 and 3.0 have Composer support, but not sure on the Composer-based differences between the two - could someone enlighten me on that?

Also, I assume I can work on the module in 2.8 only and it will be fine in 3.0? The only difference is the fact that 2.8 doesn't use the ProcessWire namespace, right?

I would not necessarily rely on composer being installed. But you can use the new psr-4 classloader of processwire, which is shipping with 2.8/3.0.

$classLoader->addNamespace('MyNamespace', $config->paths->templates . "includes/");

And if you want your module to work in both 2.8 and 3.0 simply do not use the ProcessWire namespace, which will be dynamically injected by the module/template compiler in 3.0.

  • Like 2

Share this post


Link to post
Share on other sites

@LostKobrakai - Thanks, that clears things up for me. So now, the new module will be making use of a Composer-package dependency. As you say I shouldn't necessarily rely on Composer being installed, should I go ahead and use my own Composer setup in the module directory itself?

Share this post


Link to post
Share on other sites

If you have a composer dependency than go ahead and use composer. I'd just not use it just as the autoloader.

  • Like 1

Share this post


Link to post
Share on other sites

Hi All - I've merged the previous 1.5.3-dev to master. Please let me know if you encounter any problems, and I'll patch them up as soon as I can.

Development on JL2 is going quite well - busy organising a good OOP structure for the module.

  • Like 1

Share this post


Link to post
Share on other sites

hi mike,

just wanted to say a big thank you! installed it today on a relaunched site and it works great! :)

awesome module, awesome docs!

  • Like 1

Share this post


Link to post
Share on other sites

Mike, I'll be doing some tests on my multi language install (that one we talk about in the earlier posts) but I'm afraid I can only start it in one week or so because of my other projects. But I'll let you know. :mellow:

Share this post


Link to post
Share on other sites

@Sérgio - No problem. 1.5.3 will be the last of the 1.x range - hotfixes will increment the revision by one: 1.5.31, 1.5.32, etc. I'm going to put more focus on multi-lang in v2.

Edit: Seems I didn't make a note of this somewhere, and have proceed to bump to 1.5.4. Will continue on 1.5.41, etc.

  • Like 1

Share this post


Link to post
Share on other sites

also a little feature request: what do you think of adding a "create copy" button so one could easily add new jumplinks based on existing ones?

Share this post


Link to post
Share on other sites
1 hour ago, bernhard said:

also a little feature request: what do you think of adding a "create copy" button so one could easily add new jumplinks based on existing ones?

I think that might be heading towards feature overload... Could you perhaps give an example of what kinds of jumplinks would need to be copied? I can't really imagine a situation where you would need to do this.

Share this post


Link to post
Share on other sites

Okay, so I've done a little thinking about multi-lang, and have realised that this could get quite complex, depending on the language setup of both the old and new sites. I'd like to find the simplest path that accomodates as many situations as possible.

As such, please would everyone interested in support for this feature provide me with their use-cases (other than what is mentioned below)? I'll need the following details:

  1. Source URI Example (from old site)
  2. Source Jumplink you would like to use
  3. Destination URI Example (expected URI on new site)
  4. Destination Jumplink you would like to use (not after conversion to page:n, but as you entered it into the entity editor)
  5. If the Destination Jumplink does not contain parameters (wildcards), does the resulting Page exist in the Page Tree?

I can imagine that multi-lang awareness needs to only apply to jumplinks with destinations that do not have wildcards - for example: /de/seite/. In that situation, Jumplinks would convert it to page:123, for example, but would then be converted to /en/page/. We could implement a solution by passing a {lang:code} parameter to this so that when the module runs a $pages->get(...), it would also check to see if the page is available in the specified language using $page->viewable($lang) and $page->localUrl($lang).

  • Example: Source: /{lang:de}/Seite.html Destination: /de/seite/ Saved Destination: page:123
  • User requests /de/Seite.html and is redirected to /de/seite/ via $page->viewable('de') and $page->localUrl('de'), where 'de' is obtained from the special language parameter. If the page is not viewable in German, then the module would simply redirect to the default url.

We would also use this implementation for the use-case @Sérgio presented with regards to destination selectors. The {lang:code} would not be passed to the selector itself, but would rather be checked automatically due to the presence of that parameter.

  • Example: Source: /{lang:pt}/books/book-details/{id} [Saved] Destination: [[template=books, wpid={id}]]
  • User requests /pt/books/book-details/25 and is redirected to /pt/books/title-of-the-book/ via the same methods mentioned above after the page itself is selected using the provided selector.

In both examples, we could simplify the language parameter to include all languages known to the system by simply using {lang}, without the specific language. This should cover both /something and /en/something, for example.

Everything else could well be handled by existing features, I am sure.

(Guys, note that I still haven't played around with multi-lang yet, and so all of this is coming from information provided in previous posts. If you think I've missed the ball in any way, please do let me know.)

Share this post


Link to post
Share on other sites

Hi, great module! I have a problem writing redirects, I am following documentation but still I can't make it work.

le_stampanti_a_noleggio/?m={all}

should go to

noleggio-stampanti/{all}

Is there something wrong with this settings?  Here attached the debug output.

PW 2.6.1 with Jumplinks 1.5.4

Thanks a lot!

2016-08-26-10-00-06_scrot.png

Share this post


Link to post
Share on other sites

@palacios000 - Thanks for bringing that to my attention. It appears to be a bug that seeped in from a previous change. In the early days, making trailing slashes optional involved setting them like this: [?]

However, I wanted to retain the regex format for this, and so enabled a workaround that allowed us to do this: /?

But, I didn't think about query strings after a trailing slash, and so I did not make it check for the regex optional format only at the end of the source string.

Will patch this shortly and bump to 1.5.41.

  • Like 1

Share this post


Link to post
Share on other sites

Bumped to 1.5.41 with a workaround that only allows the use of /? at the end of a source string. As JL2 is in development, trailing slashes will be dealt with differently (provided I can fix the FastRoute implementation this is now fixed, and I'm not sure how I fixed it).

Edited by Mike Rockett
  • Like 2

Share this post


Link to post
Share on other sites

Busy working on module configuration, and some questions have popped up regarding the way in which we should work with permanent and temporary redirects. I'd like to change the process to this:

  1. When creating a new jumplink, we set the 'from' and 'to' fields as normal.
  2. Then, a 'redirect type' field can be used to choose between permanent and temporary redirects.
    1. If permanent is selected, timed filtering will not be available for the jumplink, and it will redirect with HTTP status code 301.
      1. I also think that the jumplink should be completely locked if this option is selected - to the extent that the jumplink may only be deleted (which should only be done when the module has picked up that it is stale, having had no hits in the last 60 days). Not 100% sure about this, but I do like the idea. (Note: a warning would be displayed before saving if this option is selected.)
    2. If temporary is selected, then timed filtering will be made available, and it will redirect with HTTP status code 302, even if a start/end time is not specified. This will be the default option.

I'll also be implementing destination validation, which will be turned off by default. When enabled, this feature will first check to see that the resource we're redirecting to returns either of the following status codes: 200, 301, 302. We could then also turn on strict validation to ensure that the only return code allowed is 200 - this prevents the possibility of infinite redirects my simply not allowing them at all. I could go ahead and use curl to check for infinite loops, but I think that brings about some unnecessary overhead...

With the current 1.5.x branch, the module automatically uses 301 if timed activation (now known as timed filtering) is not enabled.

Thoughts, please. :)

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, Mike Rockett said:

permanent jumplink may only be deleted

I haven't yet used the module, but I'm sure sooner or later I will, so I thought I should I share what I think about this part of your question. Personally as the developer/superuser I need the possibility to edit anything that generally does not break the site. Since this is not such a feature, I think only non-superusers should be restricted, but even this restriction could be optionally disabled by the superuser, at least for a given user role specified by the dev/superuser.

Lots of small sites use at least three user role/group levels: Superuser-Editor-Guest where superuser is often the developer itself, and editor is the client. At least, this is the case with most of my sites. My clients do not want to touch things that might break the site, so they ask me to "hide" those settings.

Share this post


Link to post
Share on other sites

Not sure a restriction has the intended effect.

There are 2 cases where I regularly delete links when they are still valid:

  • when I detect a double entry (or they are part of a rule already)
  • when I see that I can replace a bunch of manually set links with a rule

What about 307 redirects?

I like the idea of a destination validation. If an infinite loop (or a redirect to another redirect within the same module) is detected it would be great to have some tool to monitor and eventually fix the problem.

  • Like 1

Share this post


Link to post
Share on other sites

@szabesz - Hmm, interesting idea. So it would be a case of allowing certain roles to modify permanent redirects. The only real reason this has come up is due to the relevant standards, which are not often adhered to. However, considering browsers don't adhere to half of the status code standards (I'm sure there are good reasons for it), perhaps I should just leave the restrictions off altogether - at the end of the day, if you want a 301, you're doing it for a reason, and you more than likely won't make too many changes to it...

@ceberlin - The only real difference between 302 and 307, the way I see it, is how HTTP methods can change when redirecting. For example, with 307, and as I understand it, changing from GET to POST requires user intervention. For the purposes of this module and its general use, I think we can stick to 302 (unless I'm missing something). Regarding validation, my intention is to keep it simple and only check for either 200, 301, 302 or just 200 (strict mode). If the former is enabled and a 301/302 is returned, Jumplinks won't check to see if that redirects to another redirect, and so on.

  • Like 2

Share this post


Link to post
Share on other sites

I am fine with that, I just heard 307 mentioned in the context of Google and the new "Strict Transport Security" feature (without understanding every detail of it).

That's ok with the loop detection. There are other tools to dig further. It would be just convenience, a redirect problem had driven me nuts recently.

  • Like 1

Share this post


Link to post
Share on other sites

Carry-over from here:

@POWERFULHORSE - Sorry to see that error came up, as we have had problems with timestamp fields in the past.
What version of MySQL are you running? There is quite a difference between 5.6 and 5.7, but understood that this problem was fixed.

Also note that (as you'll see in the posts above), Jumplinks 2 is in development, and it uses Laravel's Eloquent for database interactions. Makes it somewhat more manageable in terms of table schemas (and a whole bunch of other goodies).

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By bernhard
      --- Please use RockFinder3 ---
    • By MoritzLost
      Cacheable Placeholders
      This module allows you to have pieces of dynamic content inside cached output. This aims to solve the common problem of having a mostly cacheable site, but with pieces of dynamic output here and there.  Consider this simple example, where you want to output a custom greeting to the current user:
      <h1>Good morning, <?= ucfirst($user->name) ?></h1> This snippet means you can't use the template cache (at least for logged-in users), because each user has a different name. Even if 99% of your output is static, you can only cache the pieces that you know won't include this personal greeting. A more common example would be CSRF tokens for HTML forms - those need to be unique by definition, so you can't cache the form wholesale.
      This module solves this problem by introducing cacheable placeholders - small placeholder tokens that get replaced during every request. The replacement is done inside a Page::render hook so it runs during every request, even if the response is served from the template cache. So you can use something like this:
      <h1>Good morning, {{{greeting}}}</h1> Replacement tokens are defined with a callback function that produces the appropriate output and added to the module through a simple hook:
      // site/ready.php wire()->addHookAfter('CachePlaceholders::getTokens', function (HookEvent $e) { $tokens = $e->return; $tokens['greeting'] = [ 'callback' => function (array $tokenData) { return ucfirst(wire('user')->name); } ]; $e->return = $tokens; }); Tokens can also include parameters that are parsed and passed to the callback function. There are more fully annotated examples and step-by-step instructions in the README on Github!
      Features
      A simple and fast token parser that calls the appropriate callback and runs automatically. Tokens may include multiple named or positional parameters, as well as multi-value parameters. A manual mode that allows you to replace tokens in custom pieces of cached content (useful if you're using the $cache API). Some built-in tokens for common use-cases: CSRF-Tokens, replacing values from superglobals and producing random hexadecimal strings. The token format is completely customizable, all delimiters can be changed to avoid collisions with existing tag parsers or template languages. Links
      Github Repository & documentation Module directory (pending approval) If you are interested in learning more, the README is very extensive, with more usage examples, code samples and usage instructions!
    • By Craig
      I've been using Fathom Analytics for a while now and on a growing number of sites, so thought it was about time there was a PW module for it.
      WayFathomAnalytics
      WayFathomAnalytics is a group of modules which will allow you to view your Fathom Analytics dashboard in the PW admin panel and (optionally) automatically add and configure the tracking code on front-end pages.
      Links
      GitHub Readme & documentation Download Zip Modules directory Module settings screenshot What is Fathom Analytics?
      Fathom Analytics is a simple, privacy-focused website analytics tool for bloggers and businesses.

      Stop scrolling through pages of reports and collecting gobs of personal data about your visitors, both of which you probably don't need. Fathom is a simple and private website analytics platform that lets you focus on what's important: your business.
      Privacy focused Fast-loading dashboards, all data is on a single screen Easy to get what you need, no training required Unlimited email reports Private or public dashboard sharing Cookie notices not required (it doesn't use cookies or collect personal data) Displays: top content, top referrers, top goals and more
    • By daniels
      This is a lightweight alternative to other newsletter & newsletter-subscription modules.
      You can find the Module in the Modules directory and on Github
      It can subscribe, update, unsubscribe & delete a user in a list in Mailchimp with MailChimp API 3.0. It does not provide any forms or validation, so you can feel free to use your own. To protect your users, it does not save any user data in logs or sends them to an admin.
      This module fits your needs if you...
      ...use Mailchimp as your newsletter / email-automation tool ...want to let users subscribe to your newsletter on your website ...want to use your own form, validation and messages (with or without the wire forms) ...don't want any personal user data saved in any way in your ProcessWire environment (cf. EU data regulation terms) ...like to subscribe, update, unsubscribe or delete users to/from different lists ...like the Mailchimp UI for creating / sending / reviewing email campaigns *I have only tested it with PHP 7.x so far, so use on owners risk
      EDIT:
      Since 0.0.4, instructions and changelog can be found in the README only. You can find it here  🙂
      If you have questions or like to contribute, just post a reply or create an issue or pr on github, thanks!
    • By MoritzLost
      Sorry for the convoluted title. I have a problem with Process modules that define a custom page using the page key through getModuleInfo (as demonstrated in this excellent tutorial by @bernhard). Those pages are created automatically when the module is installed. The problem is that the title of the page only gets set in the current language. That's not a problem if the current language (language of the superuser who is installing the module) is the default language; if it isn't, the Process page is missing a title in the default language. This has the very awkward effect that a user using the backend in the default language (or any other language) will see an empty entry in the setup menu:

      This screenshot comes from my Cache Control module which includes a Process page. Now I realize the description sounds obscure, but for us it's a common setup: We a multiple bilingual sites where the default language is German and the second language is English. While the clients use the CMS in German, as a developer I prefer the English interface, so whenever I install a Process module I get this problem.
      As a module author, is there a way to handle this situation? I guess it would be possible to use post-installation hooks or create the pages manually, but I very much prefer the declarative approach. The page title is already translatable (through the __ function), but of course at the time of installation there is no translation, and as far as I'm aware it's not possible to ship translations with a module so they are used automatically. Could this situation be handled better in the core? I would prefer if the module installation process would always set the title of the Process page in the default language, instead of the language of the current user.
×
×
  • Create New...