Search

Is it possible to set up a parameter off the root URL?

I have a “sections” data type, and pages can be in a section, so I’d like to set up URLs like this:

siteroot/{$section} 
siteroot/{$section}/{$entryid}

But the page creation system automagically fills in the URL Handle field.

Marcin’s Improved Page Resolve is your friend.

Thank you!

I’m having the same question, but I get confused when I see this answer.

I thought that Symphony didn’t need a plugin/extension for every request?

Isn’t this URL question a basic need for web developers?

I thought that Symphony didn’t need a plugin/extension for every request?

This extension is if you want to pass URL parameters directly to your root page. So a URL when you pass a parameter might look like this:

http://domain.com/page/:parameter

(This Symphony allows with no extensions.)

But if you want to pass your parameter directly to the root, you’ll need an extension:

http://domain.com/:parameter

There is a case that this should be in the core of Symphony, although I’ve not personally had a project when I’ve needed to do this.

There is a case that this should be in the core of Symphony, although I’ve not personally had a project when I’ve needed to do this.

Maybe I’m not understanding this correctly - but how is it possible?

I’ve set up a section called Pages, which are supposed to be displayed as classic, static pages on the website. The front page has the root /, and I want to every other entry of the page section to be accessed from the root.

For example: www.mypage.com/ displays the front page and www.mypage.com/about displays entry About in the Pages section

And not: www.mypage.com/home/about

Isn’t this standard needs for a website?

There is a difference between pages and URL parameters in Symphony. Have a look at http://getsymphony.com/learn/concepts/pages/ for further information.

I’ve set up a section called Pages, which are supposed to be displayed as classic, static pages on the website.

Sections in Symphony are not supposed to represent an URL structure. They contain the data for your site in the backend while pages reflect the content on the frontend.

I understand the difference. But you must agree on that it’s a basic demand to able to add parameters directly after the root, without having to type www.mypage.com/home/page-name?

But you must agree on that it’s a basic demand to able to add parameters directly after the root …

No, I don’t agree, because not being able to add parameter to the root doesn’t mean you always end up with URLs like www.mypage.com/home/name. It depends on how you set up your site and how you play with pages and parameters. As pages can use the same templates most of the stuff you think you need URL parameters off the root for are possible with plain old pages.

Think of pages as fixed areas of a website (e. g. about) while URL parameters are used for variable output like filtering an archive (e. g. a page archive with URL parameters year/month/day).

But you must agree on that it’s a basic demand to able to add parameters directly after the root, without having to type www.mypage.com/home/page-name?

I agree, but a lot of CMSs don’t. Expression Engine’s index.php always showing is a prime example. This is a feature I’d like to see in the Symphony core or at least as an extension that’s maintained and in the Extension area.

I think there are two extensions that will do what you need. One was linked above. I was able to do something similar with my portfolio site by using the Static Section extension.

In Symphony 2.1, we are looking at adding this to the core.

A developer has to be careful with using root page params since non-existant physical pages are always matched as page parameters. Hence, it’s possible that 404 is never returned. In this case, the developer is responsible for making sure proper DS 404 redirect rules are implemented.

Of course, this issue still stands with sub-pages. However, instigating params on a root page effects it to a larger scale.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details