403 response on Uri.params submit

Support
1

Dear Gravists !

I’m working on a website with a “stream” of the Project-Space Theme by @OleVik.
I like the theme a lot and find the clean URLs very helpful, especially when you can list the filtered categories in the address. This is super handy !

But unfortunately it’s only working on the published website and not in local DDEV development. I’m super noob with NGINX… and I don’t even know if the problem comes from there…

So basically when I click on “APPLY”, nothing happens in the URL, the page reloads slightly (as in a fade effect), and I get the following error in the Mozilla dev console : 403 Forbidden

Does anybody have an idea of where I should dig and debug ?

Many thanks and have a nice day !
Medi

Here’s a screen cap of the error :

Screenshot_2022-03-17_15-17-29
Screenshot_2022-03-17_15-17-291853×876 102 KB

2

@medi, I’ve just installed the skeleton of Project-Space in a subdirectory of my localhost: http://localhost/grav/site-space. The home page (/projects) displays correctly, but when setting filters and running ‘Apply’ it throws an error in the console. It redirects to http://localhost/projects, which doesn’t exist.

Also the urls in the menu on the right side of the page point to the root of the site: http://localhost

I’ll happily leave the explanation to @OleVik …

1 Like
3

Thanks @pamtbaau !
Actually now that you’ve tested it, (and specifically when you mention the “/project” redirection) I noticed that there’s something to do with my website architecture.

I’ve commented out this in the tools.html.twig file, to see if it works manually :

{% if system.home.alias == '/' ~ page.slug %}
  {% set action = base_url_absolute ~ '/' ~ page.slug %}
{% else %}
  {% set action = base_url_absolute ~ page.url %}
{% endif %}

And now I don’t see any error !
But now I’ve got an other issue… the URL looks like it’s making a “query” and not a “params” format. Like follows:

https://base.tld/?category[]=Research&category[]=Sessions&redirect=true

Thanks a lot for your hint !
Apparently the FILTER part doesn’t recognize the format in the url. And I also want to make it look more readable.
I’m still looking for a way to make it work.

4

@medi, When I install the skeleton inside the root of one of my virtual hosts (e.g. http://dev-dev) on my localhost, the theme works fine. Both the filtering and the menu.

The created url when filtering are as follows: http://dev-dev/projects/category:Idea/tag:Lorem+Ipsum

5

The URL-setup is for the quite generic variant of a server-setup, as you’ve noticed for the production-server. It’s been a while since I ran DDEV, but what you’re noticing in tools.html.twig#L33-37 is done to ensure that “the page reloads slightly (as in a fade effect)” - otherwise known as PJAX (pushState + AJAX) - as intended. Navigation does actually occur, but it is obscured through animations.

I gather, from your tests, that the theme works at the root of a domain, but not in a subfolder with NGINX? I can’t see the same problem with LiteSpeed (Apache) in testing. Would you care to share more details of the NGINX/virtual host setups?

1 Like
6

@OleVik, When running the skeleton inside http://localhost/grav/project-space the theme doesn’t function correctly.

  • The menu items point to the root of the domain (http://localhost/home, http://localhost/typography)
  • Running Apply throws an error in the console pjax.min.js:1 GET http://localhost/projects/category:Idea 404 (Not Found). Also because no relative urls is being used.

The theme words fine when running in the root of a domain.

7

And this is when ran within DDEV with NGINX?

8

@OleVik, Sorry, should have mentioned my environment:

  • Windows 10/WSL2 + Ubuntu-20.04 + Apache2

NB. The skeleton is based on Grav v1.6.25 and outdated plugins.

9

I’m sorry but I’m really a beginner in this topic. I’m just using the .conf file provided in the Grav package (by copying it to the Nginx-server folder of the ddev hidden folder). It’s been working well for all the functionalities of Grav and basic theme manipulations. Basically 99% of my needs.

10

Indeed it is, I am in the process of updating it for 1.7-compliance. The issue may actually have arisen from how Core’s API treats the generation of the Base URL. It’s why tools.html.twig#L33-37 is needed, otherwise the theme is blissfully unaware of how to do the AJAXified redirects.

In other themes I’m fairly sure I have found workarounds, so it’s possible here too. Just requires some time for testing alternatives.

11

If you were so inclined, there’s a beta released which I think will remedy this. Specifically, using page.url rather than any convoluted logic in tools.html.twig and navigation.html.twig.

12

@OleVik, Using the same upgraded skeleton and after replacing the theme with the beta:

13

I believe this may be resolved with beta.3, which further simplifies the logic used for location-handling.

14

@OleVik, No errors and selection seems to be working ok.

But don’t chear yet… existing inheriting theme is now broken. Probably because of the added config property ‘colors’:

0 - An exception has been thrown during the rendering of a template (“Invalid argument supplied for foreach()”).

15

Indeed, the loss backwards-compatibility with a major-version-bump. v2.0.0 proper includes fallbacks to empty arrays if categories, tags, or colors are not set.

16

@OleVik, v2.0.0 is working correctly.