Jump to content

[Solved] Problem Upgrading to V3


prestoav
 Share

Recommended Posts

Hi all and happy Christmas!

I have an odd problem upgrading a site from 2.7.2 to 3.0.62. I've never had an issues upgrading PW versions before!

Here's the error report:

Fatal error: Exception: Unknown Selector operator: '' -- was your selector value properly escaped? field='1', value='', selector: '1' (in /Applications/MAMP/htdocs/idreamav/wire/core/Selectors.php line 396) 
#0 /Applications/MAMP/htdocs/idreamav/wire/core/Selectors.php(439): ProcessWire\Selectors->create('1', '', '') 
#1 /Applications/MAMP/htdocs/idreamav/wire/core/Selectors.php(159): ProcessWire\Selectors->extractString('1') 
#2 /Applications/MAMP/htdocs/idreamav/wire/core/Selectors.php(145): ProcessWire\Selectors->setSelectorString(Object(ProcessWire\Page)) 
#3 /Applications/MAMP/htdocs/idreamav/wire/core/PagesLoader.php(217): ProcessWire\Selectors->init(Object(ProcessWire\Page)) 
#4 /Applications/MAMP/htdocs/idreamav/wire/core/Pages.php(232): ProcessWire\PagesLoader->find(Object(ProcessWire\Page), Array) 
#5 /Applications/MAMP/htdocs/idreamav/wire/core/Wire.php(386): ProcessWire\Pages->___find(Object(ProcessWire\Page), Array) #6 /Applications/MAMP/htdocs/idreamav/wire/core/WireHooks.php(698): ProcessWire\Wire->_callMethod(' in /Applications/MAMP/htdocs/idreamav/index.php on line 64

For my eyes it looks like a selector format somewhere. I've been through all of the site templates and can; see anything wrong and they were all working under 2.7.2.

Anyone have any ideas?

Link to comment
Share on other sites

Does this happen in the frontend or backend? Did you also replace the index.php and .htaccess file?

Try deleting the site/assets/cache/ folder contents.

If that doesn't help (and you can login to the backend), try clearing the modules cache.

If that doesn't help either, disable all modules (other than core modules), and re-install one by one. Or add namespacing on the very first line of your .module files:

<?php namespace ProcessWire;

  • Like 1
Link to comment
Share on other sites

28 minutes ago, dragan said:

Does this happen in the frontend or backend? Did you also replace the index.php and .htaccess file?

Try deleting the site/assets/cache/ folder contents.

If that doesn't help (and you can login to the backend), try clearing the modules cache.

If that doesn't help either, disable all modules (other than core modules), and re-install one by one. Or add namespacing on the very first line of your .module files:

<?php namespace ProcessWire;

Hi Dragan,

Many thanks for the suggestions. I've just been through and tried all your suggestions and am still getting the same result.

Just for clarification, I'm getting the same error report for the frontend and backend of the site :-(

Link to comment
Share on other sites

Do you have Tracy Debugger installed? That might provide some additional info;

Usually when I'm doing a V2 -> V3 upgrade, i follow this procedure:

1) If I don't have the site already cloned locally, make a duplicate site on local machine to test the upgrade

- make sure you have TracyDebugger installed, force development mode
- put site into debug = true

2) check/repair permissions on files, and also check the chmod settings inside config.php (I've had upgrades seem to fail because of bad permissions)..

3) remove all modules that are known to not work on V3, for example legacy CropImage;
- also remove all modules that are not necessary for the site to run  - check which ones are in the modules folder, but are not installed and remove those.

4) Run the upgrades on the local version, and find issues, repair...;
- view logs if you get errors
- repair permissions if you get server errors but nothing in logs
- Update .htaccess, add any mods that were made to the 2x version into the 3x version (such as www/non-www, force https, custom redirects, gzip etc).

So far even on a really complex site, i've maybe found 4-5 things that needed to be fixed, and then i went to the live site, fixed those things before the upgrade, then ran the upgrade on live and it worked fine.  Make a complete backup of the live site, as well as the database, using the database backup module, prior to running the upgrade

Troubleshooting:

- If you run into modules that seem to be broken, you sometimes have to trick the filecompiler to recompile the module, you can open the module file, create a new line somewhere, save, undo, save... (this happened on a few sites)

- refresh the modules - sometimes you have to refresh modules several times to clear out errors

 

  • Like 3
Link to comment
Share on other sites

Thanks for your help Macrua. I'm running this update on localhost first so the main site is safe!

Sadly still fighting this. I've removed the modules that don't specifically report 3.0 compatibility but am still getting the error. Each time I've regressed to 2.7.2 all is well again. 

After re-reading the upgrade troubleshooting guide I've also tried the last 2.8.62 legacy version and thats' throwing the same errors as V3.

Am really struggling with this one!

Link to comment
Share on other sites

25 minutes ago, dragan said:

Did you see this thread? https://processwire.com/talk/topic/16689-exception-unknown-selector-operator/

Also, what is exactly on line 64 of index.php? And did you check perhaps your error logs? Maybe you'll find more infos there (although the above seems pretty verbose)

 

Hi Dragan,

Thanks for the link. I did look through that and I don't see an selectors with spaces :-(

Line 64 of index.php is the bit of code that makes the error output to screen by the looks of it so I assume something else is originating the error for this to fire.

Link to comment
Share on other sites

May or may not help... was getting a similar, but not quite the same, error after adding a single auto-load module. Forgot that bit and tried to load it again in a template with a local variable, eg:

$mymodule = $modules->get('myModule');

Ambiguous error was:

Error: Exception: Unknown Selector operator: '' -- was your selector value properly escaped? (in /home/xxx/xxx/wire/core/Selectors.php line 378)

TracyDebugger's error description was no more helpful than the PW logs.  While the error message was correct, it didn't truly reflect the cause of the problem. Only by disabling modules (in my case easier cos all worked before adding this particular module), and screening template code, was I able to resolve the problem.

Solution for me was to access module's methods as static functions, eg "myModule::someFunction()" in the template.

Key difference between 2.x & 3.x is namespaces. Is there a function used by index.php line 64 in your template (or _init.php or ready.php) that needs a namespace (or \)?

Link to comment
Share on other sites

  • 3 years later...

Finally found the issue!

In the template set I was using the following in various places to retrieve the root page:

$pages->get(1);

In V3 that doesn't work. However, this does:
 

$pages->get("id=1")

All works as expected once those were swapped out.

Link to comment
Share on other sites

  • prestoav changed the title to [Solved] Problem Upgrading to V3
5 hours ago, prestoav said:

In the template set I was using the following in various places to retrieve the root page:


$pages->get(1);

In V3 that doesn't work.

I think you must have something else going on that's causing the problem, because using a page ID does work in PW v3 and it's included as an example in the documentation.

// Get a page by ID
$p = $pages->get(1234);

2021-05-25_110804.png.67e4dfe20f99507a66d215884c411d13.png

  • Like 1
Link to comment
Share on other sites

10 hours ago, Robin S said:

I think you must have something else going on that's causing the problem, because using a page ID does work in PW v3 and it's included as an example in the documentation.


// Get a page by ID
$p = $pages->get(1234);

2021-05-25_110804.png.67e4dfe20f99507a66d215884c411d13.png

Hi Robin,

Yes, that was my understanding too. I have been using that for quite a while without issue.

The other thing I removed (which also maybe the cause but I don't think to) was the reference to the root page as $pages->get("/"). Maybe that was the 'root' cause? 

Link to comment
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
 Share

×
×
  • Create New...