Jump to content

Recommended Posts

34 minutes ago, Jason Huck said:

An option to automatically pass along (but otherwise not match on) query strings would be ideal...

Yeah, it can be quite a tough subject - but a checkbox should cover it well-enough. That said, do we trim out any included query string so it does not get matched if the checkbox is selected?

34 minutes ago, Jason Huck said:

A configuration option to automatically assume trailing slashes are optional would also be very handy, for the same reason. That way admins wouldn't have to remember to append ? to the end of every source URL.

This is a good idea, but I can imagine some would want a little control over it. Perhaps a global strict mode for trailing slashes (off by default, allowing both to match)?

34 minutes ago, Jason Huck said:

Another issue is that source URLs are URL encoded when stored

Jumplinks 2 no longer encodes the URI/Ls, and it is like this by default as Eloquent is used for DB interactions. However, JL1 should be decoding properly - I'll look into this. (Update, see next post)

Edited by Mike Rockett

Share this post


Link to post
Share on other sites
31 minutes ago, Jason Huck said:

path/to/this,that&theother/

This wouldn't get matched anyway - PW only allows certain characters in page names (via htaccess), and so this wouldn't be picked up. That said, JL2 has support for unicode, provided that rule 16b is turned on in htaccess. However, commas are still not supported, nor are ampersands. This rule does not apply to query strings, however.

Share this post


Link to post
Share on other sites
17 hours ago, Mike Rockett said:

Yeah, it can be quite a tough subject - but a checkbox should cover it well-enough. That said, do we trim out any included query string so it does not get matched if the checkbox is selected?

Perhaps two options when creating a new rule:

[x] Source URL may include a query string.
    [x] Append query string to target URL.

You would only use these options if you did not need to match on the contents of the query string or use it to determine the correct target URL.

 

18 hours ago, Mike Rockett said:

This is a good idea, but I can imagine some would want a little control over it. Perhaps a global strict mode for trailing slashes (off by default, allowing both to match)?

Perhaps global options like so:

[x] Trailing slash is optional for source URLs which do not end with the following extensions:
    [.html, .htm, .php, .aspx, .cfml, .pdf ...]

I suppose you could include the ability to override at the rule level, but would it even be necessary?

 

Share this post


Link to post
Share on other sites

@Jason Huck - both of those look good to me.

Regarding the first one, perhaps those options should become unavailable the second the question mark is entered?

I did think about that second one, but didn't think about filtering extensions. Perhaps a simple check for \.([a-z0-9-]{3,5})...?

Share this post


Link to post
Share on other sites
7 minutes ago, Mike Rockett said:

Regarding the first one, perhaps those options should become unavailable the second the question mark is entered?

How would you distinguish between a literal question mark and its current use to make the previous character optional? Would it have to be escaped, or is that syntax changing in v2?

 

9 minutes ago, Mike Rockett said:

I did think about that second one, but didn't think about filtering extensions. Perhaps a simple check for \.([a-z0-9-]{3,5})...?

I configurable list of allowed extensions would ultimately be safer and more flexible. People create all sorts of crazy URLs, and we don't know what someone might need to allow/disallow.

 

Share this post


Link to post
Share on other sites
Just now, Jason Huck said:

How would you distinguish between a literal question mark and its current use to make the previous character optional? Would it have to be escaped, or is that syntax changing in v2?

Because FastRoute is being used, only [/] will work in Jumplinks 2 - however, the migrator will automatically convert any saved in the old format to the new format. In fact, JL1 was only using the new format before, but then support for /? was added later on.

2 minutes ago, Jason Huck said:

I configurable list of allowed extensions would ultimately be safer and more flexible. People create all sorts of crazy URLs, and we don't know what someone might need to allow/disallow.

Also true... Perhaps I should then default it to the ext parameter type then?

Share this post


Link to post
Share on other sites
2 minutes ago, Mike Rockett said:

Also true... Perhaps I should then default it to the ext parameter type then?

Makes sense to use the same list for both purposes, as long as it's configurable. For instance, in a current project we have to handle requests for .pdf files that are now served via a PW-powered download page.

Share this post


Link to post
Share on other sites
26 minutes ago, Jason Huck said:

Makes sense to use the same list for both purposes, as long as it's configurable. For instance, in a current project we have to handle requests for .pdf files that are now served via a PW-powered download page.

Yeah, we should just default to whatever ext uses. :)

Share this post


Link to post
Share on other sites

Hi @Mike Rockett and thanks you again for your effort for solving my previous problem, but here goes new one.

Old site urls:

products/poulty.html
en/products/poulty.html

New site urls:

products/poulty/
en/products/poulty/

On new site just "products" is real page, poulty is url segment and I redirect usr segments without ending slash to url with ending slash. That is way I use ending slash in wildcards. 

Wildcard

Source: products/{name}.html/
Destination: products/{name}/

In this way it works as expected, but it doesn't cover multilaguage urls, so I try to use additional wildcard

Sorce: {lg}/products/{name}.html/
Destination: {lg}/products/{name}

I get in debug

404 Page Not Found
Checked Mon, 17 Oct 2016 15:16:23 +0300
Request: http://site.dev/en/en/products/sheep.html/
ProcessWire Version: 3.0.37

Scanning for jumplinks...

[Checking jumplink #1]
- Original Source Path:       about-us.html
- Compiled Source Path:       about-us.html

No match there...

[Checking jumplink #3]
- Original Source Path:       products/{name}.html/
- After Smart Wildcards:      products/{name:segment}.html/
- Compiled Source Path:       products/([\w_-]+).html/

No match there...

[Checking jumplink #4]
- Original Source Path:       {lg}/products/{name}.html/
- After Smart Wildcards:      {lg}/products/{name:segment}.html/
- Compiled Source Path:       {lg}/products/([\w_-]+).html/

No match there...

No matches, sorry. We'll let your 404 error page take over when Debug Mode is turned off.

As you can see in request url I have this (double "en" slug) 

Request: http://site.dev/en/en/products/sheep.html/

insted of url in address bar 

http://site.dev/en/products/sheep.html/

I don't have a clue why urs changes in request url. 

What do you think about that? Maybe I do something wrong in wildcard?  

Share this post


Link to post
Share on other sites

@Zeka - Jumplinks currently doesn't have support for multi-language sites. This will change with Jumplinks 2, where multilanguage will be implemented and quite helpful for most scenarios.

I'm not 100% sure what's happening in your case, but is it safe of me to say that Enlglish is not the default language on your site? I ask because Jumplinks uses the following piece of code to determine the site root (to prepend to the request URI) and the site root is being detected in a language that is not the default, which adds an extra en/ as that is the English site root.

$siteRoot = rtrim($this->pages->get(1)->httpUrl, '/');

So, in your case, $siteroot is en/ and the request URI is en/products/sheep.html/, which will cause the double en/. If this is the case, then I will need to change the way the module picks up on the site root.

Share this post


Link to post
Share on other sites

@Mike Rockett Yes, English is not default language.

I have this setup: 

/  - default lang
/en/ - English
/ua/ - Ukrainian

So if I have understood you correctly, the best workarout in my case is to use separete wildcards for non default languages? 

Share this post


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

So if I have understood you correctly, the best workarout in my case is to use separete wildcards for non default languages? 

Unfortunately not - as you have experienced already, this will cause the language segment to duplicate because the way I see it, the site root URI for the English language is en/ and not /. So even if you have separate jumplinks to match your default language and other languages, you will have the duplication issue.

I will need to push a fix for this as soon as I can. But first, I need to replicate your issue on my end.

Share this post


Link to post
Share on other sites

@Zeka - As I've been focused on Jumplinks 2, I completely missed that you are declaring your wildcards incorrectly. {lg} is not a valid wildcard in Jumplinks 1, and so it is treated as a string literal. You need to add :segment to that in the source only, and it should work. So your new source would become:

{lg:segment}/products/{name}.html/

In Jumplinks 2, {lg} will be a valid wildcard, and will default to the [^/]+ regular expression.

Please try the above and let me know if it works. Thanks.

 

For reference, this is the result on my side:

404 Page Not Found
Checked Mon, 17 Oct 2016 18:06:32 +0200
Request: http://playground.local/fi/product/chair.html/
ProcessWire Version: 3.0.36

Scanning for jumplinks...

[Checking jumplink #2]
- Original Source Path:       products/{name}.html/
- After Smart Wildcards:      products/{name:segment}.html/
- Compiled Source Path:       products/([\w_-]+).html/

No match there...

[Checking jumplink #1]
- Original Source Path:       {lang:segment}/product/{name}.html/
- After Smart Wildcards:      {lang:segment}/product/{name:segment}.html/
- Compiled Source Path:       ([\w_-]+)/product/([\w_-]+).html/
- - Wildcard Check:           1> lang = fi -> fi
- - Wildcard Check:           2> name = chair -> chair
- Original Destination Path:  {lang}/products/{name}/
- Compiled Destination Path:  /fi/products/chair/

Match found! We'll do the following redirect (301, permanent) when Debug Mode has been turned off:

- From URL:                   http://playground.local/fi/product/chair.html/
- To URL:                     /fi/products/chair/

 

Share this post


Link to post
Share on other sites

Hi!

I have a jumplink with wildcard:

source: index.php?id={id}
destination: {id|oldsiteid}

I don't know when (after PW3 update, or Jumplinks module update), but this jumplink stopped working,
site.com/index.id=123 just redirects to site.com now.

Any ideas why it's happens?

Share this post


Link to post
Share on other sites
2 hours ago, k07n said:

Hi!

I have a jumplink with wildcard:


source: index.php?id={id}
destination: {id|oldsiteid}

I don't know when (after PW3 update, or Jumplinks module update), but this jumplink stopped working,
site.com/index.id=123 just redirects to site.com now.

Any ideas why it's happens?

These kinds of redirects become somewhat tricky as requesting index.php is the same as requesting the root of the site. I have worked around this, but it would still be better to do this via an htaccess redirect. Unfortunately, it would be mean two redirects as you are using a mapping collection.

Just after line 129 of your htaccess file (part 13, regarding "www"), add the following:

RewriteCond %{REQUEST_URI} ^\/index\.php [NC]
RewriteCond %{QUERY_STRING} ^id=(\d+) [NC]
RewriteRule ^ /index_php/%1? [R,L]

This will redirect, for example, /index.php?id=321 to /index_php/321.

Now, change your jumplink source to /index_php/{id}.

 

Share this post


Link to post
Share on other sites
3 hours ago, Mike Rockett said:

These kinds of redirects become somewhat tricky as requesting index.php is the same as requesting the root of the site. I have worked around this, but it would still be better to do this via an htaccess redirect. Unfortunately, it would be mean two redirects as you are using a mapping collection.

Just after line 129 of your htaccess file (part 13, regarding "www"), add the following:


RewriteCond %{REQUEST_URI} ^\/index\.php [NC]
RewriteCond %{QUERY_STRING} ^id=(\d+) [NC]
RewriteRule ^ /index_php/%1? [R,L]

This will redirect, for example, /index.php?id=321 to /index_php/321.

Now, change your jumplink source to /index_php/{id}.

 

Thanks. I use nginx, but I get the idea.

  • Like 1

Share this post


Link to post
Share on other sites

Hi @Mike Rockett

If I have 2 non ProcessWire files on my site and want to redirect A to B, will PW handle that for me?

I'm guessing not and that I need to manually edit their html or the .htaccess file?

Just assumed that they would be redirected as even though they're not PW pages, they're served up within a PW site.

Share this post


Link to post
Share on other sites

Hi @Peter Knight

If they are served up in the PW site, then the 404 event won't take place, so Jumplinks won't even start the process at all.

mod_rewrite/mod_alias would be the most efficient in this simple scenario.

  • Like 1

Share this post


Link to post
Share on other sites

I tried to use "|" in the selector but didn't worked:

[[template=tutor|event,name={pagename}]]

Result:

domain.com/[[template=tutor%7Cevent,name=...]]

Using only "tutor" or "event" works fine though. Is this a bug or is this not supported? (v1.5)

Plus a question to v2: will it have a feature to add a name to each jumplink? That would make it easier to see what the jumplink does, e.g "Redirect old events to page Events". They would be even searchable using the browser search feature or with filterbox feature of AdminOnSteroids.

Share this post


Link to post
Share on other sites
3 hours ago, tpr said:

I tried to use "|" in the selector but didn't worked

Sorry about that - more than likely an oversight on my end. Will review and see what can be done.

3 hours ago, tpr said:

will it have a feature to add a name to each jumplink?

When I began working on this module, naming support was present. In the first alphas, however, it was indicated that this was not the greatest idea, and so the feature was removed.

Jumplinks 2 uses Datatables with a filterbox. Most of the time, you would find that a name contains a keyword from either the source or the destination, and so you could enter that specific keyword into the filter box. Per your example, that title would have the keyword event in it - searching for that would yield pretty much the same result. As such, I don't plan on adding name support, especially considering the bulk it adds to the user interface.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks, works like charm!

As for the names I trust your experience :) Anyway, such names (descriptions?) wouldn't do so much harm to the UI.

jumplinks-title.png

Share this post


Link to post
Share on other sites
9 minutes ago, tpr said:

Thanks, works like charm!

As for the names I trust your experience :) Anyway, such names (descriptions?) wouldn't do so much harm to the UI.

jumplinks-title.png

Interestingly, that does look quite nice. I've emulated that with one row on the new design, and it would definitely need a little tweaking. My issue, though, is that the UI would like quite inconsistent, as you can tell, when some links have descriptions and others do not.

scrn_jumplinks.rockettpw.local-2016-12-12-15-10-45.png

(Note: The Type column has not been finalised yet - there will be SVG icons there, as per previous screenshots.)

I know this is maybe not the perfect idea, but what about a tooltip? That way, it doesn't reduce the density of the table, and you can still easily see the description of a link if it is not easily understood.

  • Like 1

Share this post


Link to post
Share on other sites

just chiming in.. wanted to +1 for the idea of names/descriptions;
and i would have no problem with the inconsistency of some not having descriptions.. hopefully it's not too much extra work (?)

 

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 d'Hinnisdaël
      Happy new year, everybody 🥬
      I've been sitting on this Dashboard module I made for a client and finally came around to cleaning it up and releasing it to the wider public. This is how it looks.
      ProcessWire Dashboard

      If anyone is interested in trying this out, please go ahead! I'd love to get some feedback on it. If this proves useful and survives some real-world testing, I'll add this to the module directory.
      Download
      You can find the latest release on Github.
      Documentation
      Check out the documentation to get started. This is where you'll find information about included panel types and configuration options.
      Custom Panels
      My goal was to make it really simple to create custom panels. The easiest way to do that is to use the panel type template and have it render a file in your templates folder. This might be enough for 80% of all use cases. For anything more complex (FormBuilder submissions? Comments? Live chat?), you can add new panel types by creating modules that extend the DashboardPanel base class. Check out the documentation on custom panels or take a look at the HelloWorld panel to get started. I'm happy to merge any user-created modules into the main repo if they might be useful to more than a few people.
       Disclaimer
      This is a pre-release version. Please treat it as such — don't install it on production sites. Just making sure 🍇
      Roadmap
      These are the things I'm looking to implement myself at some point. The wishlist is a lot longer, but those are the 80/20 items that I probably won't regret spending time on.
      Improve documentation & add examples ⚙️ Panel types Google Analytics ⚙️ Add new page  🔥 Drafts 🔥 At a glance / Page counter 404s  Layout options Render multiple tabs per panel panel groups with heading and spacing between ✅ panel wrappers as grid item (e.g. stacked notices) ✅ Admin themes support AdminThemeReno and AdminThemeDefault ✅ Shortcuts panel add a table layout with icon, title & summary ✅ Chart panel add default styles for common chart types ✅ load chart data from JS file (currently passed as PHP array) Collection panel support image columns ✅ add buttons: view all & add new ✅
    • By Pip
      Hi everyone!
      I'm trying out the Login/Register module for my site. Noted that the module assigns the newly registered user to login-register role. 
      Once you modify the login-register role's permissions, particularly adding page-edit, the new member role will be set to guest. 
      Thing is I'd like to grant my new users the power to create their own pages. Any advice? 
      Thanks. 
    • By Gadgetto
      SnipWire - Snipcart integration for ProcessWire
      Snipcart is a powerful 3rd party, developer-first HTML/JavaScript shopping cart platform. SnipWire is the missing link between Snipcart and the content management framework ProcessWire.
      With SnipWire, you can quickly turn any ProcessWire site into a Snipcart online shop. The SnipWire plugin helps you to get your store up and running in no time. Detailed knowledge of the Snipcart system is not required.
      SnipWire is free and open source licensed under Mozilla Public License 2.0! A lot of work and effort has gone into development. It would be nice if you could donate an amount to support further development:

      Status update links (inside this thread) for SnipWire development
      2020-07-03 -- SnipWire 0.8.7 (beta) released! Fixes some small bugs and adds an indicator for TEST mode 2020-04-06 -- SnipWire 0.8.6 (beta) released! Adds support for Snipcart subscriptions and also fixes some problems 2020-03-21 -- SnipWire 0.8.5 (beta) released! Improves SnipWires webhooks interface and provides some other fixes and additions 2020-03-03 -- SnipWire 0.8.4 (beta) released! Improves compatibility for Windows based Systems. 2020-03-01 -- SnipWire 0.8.3 (beta) released! The installation and uninstallation process has been heavily revised. 2020-02-08 -- SnipWire 0.8.2 (beta) released! Added a feature to change the cart and catalogue currency by GET, POST or SESSION param 2020-02-03 -- SnipWire 0.8.1 (beta) released! All custom classes moved into their own namespaces. 2020-02-01 -- SnipWire is now available via ProcessWire's module directory! 2020-01-30 -- SnipWire 0.8.0 (beta) first public release! (module just submitted to the PW modules directory) 2020-01-28 -- added Custom Order Fields feature (first SnipWire release version is near!) 2020-01-21 -- Snipcart v3 - when will the new cart system be implemented? 2020-01-19 -- integrated taxes provider finished (+ very flexible shipping taxes handling) 2020-01-14 -- new date range picker, discount editor, order notifiactions, order statuses, and more ... 2019-11-15 -- orders filter, order details, download + resend invoices, refunds 2019-10-18 -- list filters, REST API improvements, new docs platform, and more ... 2019-08-08 -- dashboard interface, currency selector, managing Orders, Customers and Products, Added a WireTabs, refinded caching behavior 2019-06-15 -- taxes provider, shop templates update, multiCURL implementation, and more ... 2019-06-02 -- FieldtypeSnipWireTaxSelector 2019-05-25 -- SnipWire will be free and open source Plugin Key Features
      Fast and simple store setup Full integration of the Snipcart dashboard into the ProcessWire backend (no need to leave the ProcessWire admin area) Browse and manage orders, customers, discounts, abandoned carts, and more Multi currency support Custom order and cart fields Process refunds and send customer notifications from within the ProcessWire backend Process Abandoned Carts + sending messages to customers from within the ProcessWire backend Complete Snipcart webhooks integration (all events are hookable via ProcessWire hooks) Integrated taxes provider (which is more flexible then Snipcart own provider) Useful Links
      SnipWire in PW modules directory SnipWire Docs (please note that the documentation is a work in progress) SnipWire @GitHub (feature requests and suggestions for improvement are welcome - I also accept pull requests) Snipcart Website  

       
      ---- INITIAL POST FROM 2019-05-25 ----
       
    • By Sten
      Hello
      Till now I hacked something with the twig template but it works no more with new PW versions so I look forward to create a module. I am working on a site in multiple languages : French, English, Italian, German, Spanish, Portuguese, Hebrew, Russian. The new posts are entered in any language with a field for language. Till now, I got twig files to get the translations with constants defined for each part of the pages.
      So I'd like to create a module to include theses files added according to the url /fr/en/...
      Have you some observations to do before I begin about the direction to take ?
      Thank you
    • By ukyo
      Mystique Module for ProcessWire CMS/CMF
      Github repo : https://github.com/trk/Mystique
      Mystique module allow you to create dynamic fields and store dynamic fields data on database by using a config file.
      Requirements
      ProcessWire 3.0 or newer PHP 7.0 or newer FieldtypeMystique InputfieldMystique Installation
      Install the module from the modules directory:
      Via Composer:
      composer require trk/mystique Via git clone:
      cd your-processwire-project-folder/ cd site/modules/ git clone https://github.com/trk/Mystique.git Module in live reaction with your Mystique config file
      This mean if you remove a field from your config file, field will be removed from edit screen. As you see on youtube video.
      Using Mystique with your module or use different configs path, autoload need to be true for modules
      Default configs path is site/templates/configs/, and your config file name need to start with Mystique. and need to end with .php extension.
      Adding custom path not supporting anymore !
      // Add your custom path inside your module class`init` function, didn't tested outside public function init() { $path = __DIR__ . DIRECTORY_SEPARATOR . 'configs' . DIRECTORY_SEPARATOR; Mystique::add($path); } Mystique module will search site/modules/**/configs/Mystique.*.php and site/templates/Mystique.*.php paths for Mystique config files.
      All config files need to return a PHP ARRAY like examples.
      Usage almost same with ProcessWire Inputfield Api, only difference is set and showIf usage like on example.
      <?php namespace ProcessWire; /** * Resource : testing-mystique */ return [ 'title' => __('Testing Mystique'), 'fields' => [ 'text_field' => [ 'label' => __('You can use short named types'), 'description' => __('In file showIf working like example'), 'notes' => __('Also you can use $input->set() method'), 'type' => 'text', 'showIf' => [ 'another_text' => "=''" ], 'set' => [ 'showCount' => InputfieldText::showCountChars, 'maxlength' => 255 ], 'attr' => [ 'attr-foo' => 'bar', 'attr-bar' => 'foo' ] ], 'another_text' => [ 'label' => __('Another text field (default type is text)') ] ] ]; Example:
      site/templates/configs/Mystique.seo-fields.php <?php namespace ProcessWire; /** * Resource : seo-fields */ return [ 'title' => __('Seo fields'), 'fields' => [ 'window_title' => [ 'label' => __('Window title'), 'type' => Mystique::TEXT, // or InputfieldText 'useLanguages' => true, 'attr' => [ 'placeholder' => __('Enter a window title') ] ], 'navigation_title' => [ 'label' => __('Navigation title'), 'type' => Mystique::TEXT, // or InputfieldText 'useLanguages' => true, 'showIf' => [ 'window_title' => "!=''" ], 'attr' => [ 'placeholder' => __('Enter a navigation title') ] ], 'description' => [ 'label' => __('Description for search engines'), 'type' => Mystique::TEXTAREA, 'useLanguages' => true ], 'page_tpye' => [ 'label' => __('Type'), 'type' => Mystique::SELECT, 'options' => [ 'basic' => __('Basic page'), 'gallery' => __('Gallery'), 'blog' => __('Blog') ] ], 'show_on_nav' => [ 'label' => __('Display this page on navigation'), 'type' => Mystique::CHECKBOX ] ] ]; Searching data on Mystique field is limited. Because, Mystique saving data to database in json format. When you make search for Mystique field, operator not important. Operator will be changed with %= operator.
      Search example
      $navigationPages = pages()->find('my_mystique_field.show_on_nav=1'); $navigationPages = pages()->find('my_mystique_field.page_tpye=gallery');
×
×
  • Create New...