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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Gadgetto
      Status update links (inside this thread) for SnipWire development will be always posted here:
      2019-10-18
      2019-08-08
      2019-06-15
      2019-06-02
      2019-05-25
      If you are interested, you can test the current state of development:
      https://github.com/gadgetto/SnipWire
      Please note that the software is not yet intended for use in a production system (alpha version).
      If you like, you can also submit feature requests and suggestions for improvement. I also accept pull requests.
      ---- INITIAL POST FROM 2019-05-25 ----
      I wanted to let you know that I am currently working on a new ProcessWire module that fully integrates the Snipcart Shopping Cart System into ProcessWire. (this is a customer project, so I had to postpone the development of my other module GroupMailer).
      The new module SnipWire offers full integration of the Snipcart Shopping Cart System into ProcessWire.
      Here are some highlights:
      simple setup with (optional) pre-installed templates, product fields, sample products (quasi a complete shop system to get started immediately) store dashboard with all data from the snipcart system (no change to the snipcart dashboard itself required) Integrated REST API for controlling and querying snipcart data webhooks to trigger events from Snipcart (new order, new customer, etc.) multi currency support self-defined/configurable tax rates etc. Development is already well advanced and I plan to release the module in the next 2-3 months.
      I'm not sure yet if this will be a "Pro" module or if it will be made available for free.
      I would be grateful for suggestions and hints!
      (please have a look at the screenshots to get an idea what I'm talking about)
       




    • By eelkenet
      Hi! I've created a small Inputfield module called InputfieldFloatRange which allows you to use an HTML5 <input type="range" ../> slider as an InputField. I needed something like this for a project where the client needs to be able to tweak this value more based on 'a feeling' than just entering a boring old number. Maybe more people can use this so I'm hereby releasing it into the wild.  
       
      What is it?
      The missing range slider Inputfield for Processwire. 
      What does it do?
      This module extends InputfieldFloat and allows you to use HTML5 range sliders for number fields in your templates.
      It includes a visible and editable value field, to override/tweak the value if required.  
      Features
      Min/max values Precision (number of decimals) Steps (Read more) Manual override of the selected value (will still adhere to the rules above) Usage
      Clone / zip repo Install FieldtypeFloatRange, this automatically installs the Inputfield Create new field of type `Float (range)` or convert an existing `Float`, `Integer` or `Text` field. To render the field's value simply echo `$page->field` Demo
      A field with Min=0, Max=1, Step=0.2, Precision=2

      Field with settings Min=0, Max=200, Step=0.25, Precision=2

       
      Todo
      Make the display-field's size configurable (will use the Input Size field setting)  Hopefully become redundant If it's usable for others I'll add it to the Modules list  
      Changelog
      v002
      - Fix issue where setting the step value to an empty value created problem with validation
      - Make the display-field optional 
      v001
      - Initial release
       
      Thanks!
       
       
    • By Robin S
      Another little admin helper module...
      Template Field Widths
      Adds a "Field widths" field to Edit Template that allows you to quickly set the widths of inputfields in the template.

      Why?
      When setting up a new template or trying out different field layouts I find it a bit slow and tedious to have to open each field individually in a modal just to set the width. This module speeds up the process.
      Installation
      Install the Template Field Widths module.
      Config options
      You can set the default presentation of the "Field widths" field to collapsed or open. Field widths entered into the Template Field Widths inputfield are only applied if the Edit Template form is submitted with the Template Field Widths inputfield in an opened state. "Collapsed" is the recommended setting if you think you might also use core inputs for setting field widths in a template context. You can choose Name or Label as the primary identifier shown for the field. The unchosen alternative will become the title attribute shown on hover. You can choose to show the original field width next to the template context field width.  
      https://github.com/Toutouwai/TemplateFieldWidths
      https://modules.processwire.com/modules/template-field-widths/
    • By adrian
      Tracy Debugger for ProcessWire
      The ultimate “swiss army knife” debugging and development tool for the ProcessWire CMF/CMS

       
      Integrates and extends Nette's Tracy debugging tool and adds 35+ custom tools designed for effective ProcessWire debugging and lightning fast development
      The most comprehensive set of instructions and examples is available at: https://adrianbj.github.io/TracyDebugger
      Modules Directory: http://modules.processwire.com/modules/tracy-debugger/
      Github: https://github.com/adrianbj/TracyDebugger
      A big thanks to @tpr for introducing me to Tracy and for the idea for this module and for significant feedback, testing, and feature suggestions.
×
×
  • Create New...