Posted by Matt75 on Sun, Feb 23, 2025 - 9:13am

Hello,

I am currently updating a Drupal 7 site to Backdrop CMS.

In the Drupal 7 site, I retrieved URL parameters in several places using $_GET['parameter']. For example, in blocks (PHP filter) or PHP code in Views → Contextual Filters (default value / validation criteria). This always worked without any issues.

In Backdrop CMS, with a manually installed PHP filter, I never get a value using $_GET.
For the URL .../test?title=testtitle, the following code:
<?php print_r($_GET['title']); ?>
only returns an empty output.

Does anyone have an idea what the issue could be?
 

Accepted answer

As for the PHP filter module - this may be a separate problem. PHP filter doesn't have a release in BAckdrop and will not have one, and the last merge was done 3 years ago. There are ways to avoid using PHP filter. If you post here about your intended use, someone may be able to help.

Comments

Sun, Feb 23, 2025 - 9:36am by argiepiano

Are you using the  <?php ?> tag when you set up the contextual filter in Views → Contextual Filters (default value / validation criteria)? 

It should not be used, according to the directions there.

In my testing, this is working just fine. This is what I'm doing:

  1. Edit the view node_admin_content at admin/structure/views/view/node_admin_content
  2. Add a contextual filter for nid
  3. Select "Provide default value"
  4. Enter this (obviously just for this test, it will never work in a different context) 
debug($_GET['title']);
return 1;

5. Save everything. PLEASE NOTICE: print doesn't seem  to work in this context (the print output gets flushed out when building the output). So, you must use debug() to output this value!

6. Visit admin/content/node?title=first&type=All&status=All in a clean install of BAckdrop

You get this:

 

Sun, Feb 23, 2025 - 9:38am by argiepiano

As for the PHP filter module - this may be a separate problem. PHP filter doesn't have a release in BAckdrop and will not have one, and the last merge was done 3 years ago. There are ways to avoid using PHP filter. If you post here about your intended use, someone may be able to help.

Mon, Feb 24, 2025 - 12:50am by Matt75

Thanks for the help.

In Views contextual filters, $_GET actually works.

However, it doesn’t seem to work in blocks or nodes with the PHP filter (which is what I had mainly tested so far). I’ll have to take a closer look at the PHP filter.

 

Mon, Feb 24, 2025 - 3:46am by Matt75

OK, I found the problem:
With the PHP Filter, $_GET does not seem to work when a site is in Maintenance mode.
Once I deactivated Maintenance mode, $_GET started working...

Mon, Feb 24, 2025 - 5:51am by argiepiano

Ok, glad to hear it works for you. Can you mark your answer as "correct" and also mine as "helpful"? This will help people search for answers in the future.

Wed, Feb 26, 2025 - 9:07am by Coffee70

May I append a question here?

I seem to have a similar issue:
Two Backdrop 1.30.1 portals, both running on the same server (Apache, PHP, MariaDB), both with the same enabled modules and theme.
Both have the same Apache confs, and - as far as I can see - the same settings in the .htaccess file for rewrite rules.

Difference:

  • One Backdrop 1.30.1 portal is a completely fresh installation.
  • The other Backdrop 1.30.1 portal is an upgrade from Drupal 7, which works fine and shows no error messages. Of course, settings and content have been taken over from the Drupal 7 portal.

No matter what I try, $_GET

  • works in the fresh installation
  • does not work in the Drupal 7 upgrade—no URL parameters are returned at all:
    $_GET['parameter'] is empty
    $_GET only shows Array ( [q] => node/100 )

Maintenance mode is off.
I have tested this on pages with the PHP filter, as well as with Views cont. filters, etc.

Where could the problem be? Something with the redirection on the Drupal Update?

===

Enabled modules on both portals
============================

Core
----------
admin_bar                    1.30.1
block                        1.30.1
color                        1.30.1
comment                      1.30.1
config                       1.30.1
contextual                   1.30.1
date                         1.30.1
dblog                        1.30.1
entity                       1.30.1
field                        1.30.1
field_sql_storage            1.30.1
field_ui                     1.30.1
file                         1.30.1
filter                       1.30.1
image                        1.30.1
language                     1.30.1
layout                       1.30.1
list                         1.30.1
locale                       1.30.1
menu                         1.30.1
node                         1.30.1
number                       1.30.1
options                      1.30.1
path                         1.30.1
search                       1.30.1
system                       1.30.1
taxonomy                     1.30.1
text                         1.30.1
translation                  1.30.1
update                       1.30.1
user                         1.30.1
views                        1.30.1
views_ui                     1.30.1

Contrib
-------
addressfield                 1.x-1.3.2
clone                        1.x-1.1.6
colorbox                     1.x-2.17.2
entity_plus                  1.x-1.0.21
geocoder                     1.x-1.0.2
geofield                     1.x-1.0.4
globalredirect               1.x-1.6.0
honeypot                     1.x-1.26.1
leaflet                      1.x-1.2.0
metatag                      1.x-1.22.6
metatag_views                1.x-1.22.6
print                        1.x-2.4.0-beta6
print_ui                     1.x-2.4.0-beta6
views_bulk_operations        1.x-3.0.6
webform                      1.x-4.26.3
webform_validation           1.x-1.16

Wed, Feb 26, 2025 - 10:03am by yorkshirepudding

For the D7 upgrade site:

Check in Admin Bar > Configuration > URL handling > URL settings

Is 'Enable clean URLs' checked?

Thu, Feb 27, 2025 - 3:58am by Coffee70

Yes. 
In both portals 'Enable clean URLs' is checked.

 

Thu, Feb 27, 2025 - 5:24am by argiepiano

Are you using a special version of .htaccess in your root? Or is it the one provided by the Backdrop codebase? And are both sites in the same server?

Thu, Feb 27, 2025 - 5:48am by Coffee70

Both are on the same server.
Both have the original .htaccess from the Backdrop ZIP.

Both have the same modules.

The only difference:
The new Backdrop portal has the default settings of a fresh Backdrop and new module installation.

The Drupal updated portal contains around 100 existing nodes of a specific node type, their existing paths, the old Drupal file folder, and the old settings from the Drupal site.

Perhaps some configuration settings are missing or something similar...
 

Thu, Feb 27, 2025 - 5:52am by argiepiano

This sounds like a bug. The first step is to try to reproduce this on a clean D7 upgrade to see if this affects  the clean URLs. 

So, other than the $_GET, you ARE seeing clean URLs in the browser for the upgraded site?

Thu, Feb 27, 2025 - 9:01am by Coffee70

Yes, I see clean URLs in the browser for the upgraded site.

Thu, Feb 27, 2025 - 7:22am by argiepiano

Here's another random thought. Can you disable globalredirect in the D7 site and try again?

Thu, Feb 27, 2025 - 9:02am by Coffee70

I have tested this with deactivated globalredirect module. S_GET still did not work.

Thu, Feb 27, 2025 - 9:04am by Coffee70

After thoroughly comparing the entire UI configuration, .htaccess, and /files/configxx/active/*.json without finding any differences, I decided to restart Apache multiple times and repeatedly clear all caches under /admin/config/development/performance.

Until now, I had only clicked "Clear all caches" once.

After clearing the caches about 10 times in a row, $_GET has slowly started working again on some subpages. Not all of them yet, but let's see how it develops.

Thu, Feb 27, 2025 - 9:25am by argiepiano

Also try clearing your BROWSER'S cache, or open the site on a different browser.