Jump to content

Pages Web Service and Processwire 3.0


celfred
 Share

Recommended Posts

Hello,

I'm desperately trying to update my website to PW 3.0.62 and I'm facing issues to to module compatibility. I was stuck with Pages2Pdf which I managed to solve bu updating the module from Github, but now it's the Pages Web Service module... and this time, I don't know wht to do :(

The Module is found there. But it is quite old and I can't find it in the modules catalogue... and my site is making quite a use of it (I can't think of a way to do otherwise, sorry...)

After adding the FileCompiler=0 to the module pages, the error I'm stuck with is :

Fatal error: Class 'WireData' not found in /home/celfred/PlanetAlert/site/modules/ServicePages/ServicePages.module on line 22

and I have no idea on what to do... I must admit I'm not a programmer but a middle-school teacher... (for your information, here's the site I'm talking about : http://planetalert.tuxfamily.org ) but I'm struggling hard to solve the different issues I have to face and I'm wlling to understand things. I have just spent many hours trying to make 2.8 work on my localhost (and it seems ok :) ) but I'd like to switch to 3.x to prepare the future ;)

If anyone had the will to spend a few minutes to try and help me, I would greatly appreciate.

Thanks in advance !

If you need more information to understand my problem, feel free to ask.

Link to comment
Share on other sites

So cool ! I can't believe it was so... simple... I added this line on my templates files, but didn't think it was needed in modules as well.

Now, I'll try and face the other issues by myself, but it went a little further. That's cool !

Thanks a lot for your help !

  • Like 1
Link to comment
Share on other sites

I must admit I'm completely lost on those issues. I have turned off the compiler on my first fatal error that occurred with another module : Pages2Pdf. As I said earlier, I downloaded the last Github version of that module and noticed in the source the FileCompiler=0 line, so I simply did the same in the Service Pages modules :)

Now when trying to get rid of all lines (FileCompiler and namespace) it seems to work as well (?) . Maybe I'm still having a cache somewhere messing up with all my tests, but it seems to work anyway so that's good !

I am now continuing debugging my local site. I have to add the namespace line at some places to get rid of error messages. But all in all, it looks quite correct.

One of my pages trigger a 'big' fatal error that is again over my head for the moment :

Error: Exception: SQLSTATE[42000]: Syntax error or access violation: 1055 Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'planetalert._sort_page_group_name.name' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by (in /home/celfred/PlanetAlert/wire/core/PageFinder.php line 384)

(The page worked fine with PW 2.8). But that's another problem and it's not on a 'major' page ;)

Thanks for your concern @adrian

Link to comment
Share on other sites

That fatal error is an interesting one and suggests a possible bug in ProcessWire. You should not have to (and probably shouldn't) disable that mysql setting. I would like to know what selector in your template (that calls the PageFinder) is resulting in that error. Is it possible for you to narrow that error down to a specific $pages->find selector?

  • Like 1
Link to comment
Share on other sites

Here's what I did :

  • Restarted mysql to be back with the initial fatal error.
  • Found out that commenting out the line : $allPlayers = $pages->find("template=player, team=$team, sort=group"); got rid of the error
  • Replaced the line with : $allPlayers = $pages->find("template=player, team=$team")->sort("group"); and... It works :)

That's indeed a cleaner solution better than changing my mysql settings. I guess the 'bug' was on my side with the 'sort' command included in my 'find' query. I have to revise the PW doc to see where I saw that syntax or if I made it up without noticing that it never worked (which is possible !).

So thanks for pointing this out to me !

 

Link to comment
Share on other sites

Last thing for the moment while trying to update to PW 3.x : in backend, my modulemanager page tries to read a modulemanager.cache file in files/assets/cache which doesn't exist hence error messages :

Warning: fread(): Length parameter must be greater than 0 in /home/celfred/PlanetAlert/site/modules/ModulesManager/ModulesManager.module on line 812

ProcessWire: ModulesManager: cannot read cache file /home/celfred/PlanetAlert/site/assets/cache/ModuleManager.cache

(with debug true)

 

Link to comment
Share on other sites

What type of field is "group" ? 

There doesn't appear to be anything wrong with your original selector, but I am wondering if maybe it's a Page Reference or Options field type.

It would be great to see exactly what the SQL query is (the one coming from that selector). Do you have TracyDebugger installed? If so, take a look at the PDO queries section of the debug mode panel and see if you can find the query for us please.

Link to comment
Share on other sites

1 minute ago, celfred said:

Warning: fread(): Length parameter must be greater than 0 in /home/celfred/PlanetAlert/site/modules/ModulesManager/ModulesManager.module on line 812

The modules manager module hasn't been tagged as PW 3 compatible. I honestly don't really think it is necessary these days - we have such an easy way of installing modules directly in PW by their class name.

  • Like 2
Link to comment
Share on other sites

I have the TracyDebugger installed and I'll try to do what you're asking me with pleasure, but I have to stop right now (time to eat at home, daughters hungry... :) ) I'll do that tomorrow and keep you updated about my progress.

And I agree with your advice about installing modules directly from within ProcessWire. It is indeed quite simple :)

  • Like 1
Link to comment
Share on other sites

Hello,

I'm back to it and it's not easy :) 203 PDO queries in my Tracydebugger ! That sounds like a lot to me... I have tried to isolate the 'responsible' one and here it is (I think) :

SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` JOIN field_team AS field_team ON field_team.pages_id=pages.id AND ((((field_team.data='85366') ) )) LEFT JOIN field_group AS _sort_group ON _sort_group.pages_id=pages.id LEFT JOIN pages AS _sort_page_group_name ON _sort_group.data=_sort_page_group_name.id WHERE (pages.templates_id=43) AND (pages.status<1024) GROUP BY pages.id ORDER BY _sort_page_group_name.name

This corresponds to the following statement :

$allPlayers = $pages->find("template=player, team=$team, sort=group");

Answering your question : the 'group' field is indeed a 'Page' type. It used to be a 'Text' type so I tried and changed my find query replacing 'sort=group' by 'sort=group.name' and the error is still there. Here's the resulting PDO query in Tracydebugger :

SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` JOIN field_team AS field_team ON field_team.pages_id=pages.id AND ((((field_team.data='85366') ) )) LEFT JOIN field_group AS _sort_group_name ON _sort_group_name.pages_id=pages.id LEFT JOIN pages AS _sort_page_group_name ON _sort_group_name.data=_sort_page_group_name.id WHERE (pages.templates_id=43) AND (pages.status<1024) GROUP BY pages.id ORDER BY _sort_page_group_name.name

As I said earlier, if I change the syntax to :

$allPlayers = $pages->find("template=player, team=$team")->sort("group.name");

The PDO query shows :

SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` JOIN field_team AS field_team ON field_team.pages_id=pages.id AND ((((field_team.data='85366') ) )) WHERE (pages.templates_id=43) AND (pages.status<1024) GROUP BY pages.id

and everything works as expected.

I've tried my best to be helpful. I hope I've managed to isolate the correct lines and that you can understand something out of it. (and that I'm not responsible for taking this time from you... by responsible, I mean that I did something wrong that caused the problem, which can be a possibility)

Sidenote : Trying to isolate the query, I took almost everything out of my page (no more find/get statement except that one, no more head.inc, foot.inc....) and I still have either 41 or 38 (depending on reload) PDO queries on my page). I would imagine that's PW 'doing his job'. Is that so ?

 

Link to comment
Share on other sites

PW does tend to make use of a lot of efficient sql queries, so even though 203 queries are a lot, they are normal and fine in PW.

Something I had forgotten about - PW actually disables the MySQL only_full_group_by setting. Whether this is the correct approach or not is debatable, but that is how it is currently supposed to work, but it seems like it only works for MySQL 5.7.0 or greater, so I am guessing you have an earlier version that still has the only_full_group_by setting enabled.

What you can do though is add the following to your /site/config.php file:

$config->dbSqlModes = array(
    "5.6.0" => "remove:STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY"
);

Note that I have used 5.6.0 as an example - you will need to find the version of MySQL that you are running and use that instead.

This should take care of all those errors.

Please let us know how it goes.

Link to comment
Share on other sites

Well, I've checked my localhost version and it gives 5.7.19.

Anyway, I've changed my line taking the 'sort' out of my 'find' string and it works (actually, I believe my 'sort' command is not really useful on my page any longer so it's not really an issue for me any longer). I've taken care of most of my errors (I think) and it seems to work fine.

I went ahead and made the changes on my live site. It looks ok. I'll test tomorrow when actually saving data 'for real', but on my localhost it works, so that's cool ! I'm running on PW 3.0.36 now :)

Thanks a lot for your help !

If anything still matters to you and you suspect a weird behavior on PW side and you want to dig this a little, don't hesitate asking me for further testing or information.

Link to comment
Share on other sites

9 minutes ago, celfred said:

If anything still matters to you and you suspect a weird behavior on PW side and you want to dig this a little, don't hesitate asking me for further testing or information.

Thanks - actually it would be great if you could enter this in the Tracy console panel and tell me what it returns:

d($config->dbSqlModes);
$minVersion = '5.7.0';
$serverVersion = $database->getAttribute(\PDO::ATTR_SERVER_VERSION);
if(version_compare($serverVersion, $minVersion, '<')) d('false');

 

Link to comment
Share on other sites

5 minutes ago, celfred said:

It returns 'NULL'. How does that sound ?

It sounds like there is something missing from your /wire/config.php or your /site/config.php is overwriting the $config->dbSqlModes setting in /wire/config.php

That might explain why the ONLY_FULL_GROUP_BY is not being disabled.

Could you please post both of those config.php files - PM them to me if you prefer.

PS - this is what I see:

59b54ac30008b_ScreenShot2017-09-10at7_22_29AM.thumb.png.e9b0062daa3e9e465db435fa4d7766af.png

Link to comment
Share on other sites

7 minutes ago, celfred said:

I PMed you the files so as not to 'pollute' this post with unnecessary lines.

Thanks - I took a look and your /wire/config.php file is missing these lines:

https://github.com/processwire/processwire/blob/57b297fd1d828961b20ef29782012f75957d6886/wire/config.php#L869-L906

I just realized the issue - you mentioned that you are running PW 3.0.36. The latest stable version is 3.0.62 and the latest dev is 3.0.74.

If you update to either one of those, all your errors should go away.

I am curious how you ended up with 3.0.36 - where did you download that from?

OT - did you intentionally restyle (colors) the Tracy console panel, or is that CSS leaking through from your site somehow?

  • Like 1
Link to comment
Share on other sites

Here's what I think : I had an 'old' processwire directory which I downloaded through Git and which I thought was up-to-date with master (not dev branch) so I really imagined I was with 3.0.62. (I'm sure I did a git pull but I guess not...)

And today I added PW version in my footer and saw 3.0.36 and imagined I forgot about the version number _ must have been 3.0.32 and they've already made some changes and now it's 3.0.36... Anyway, you see how good I am with Git and some stuff :)

So I'm really sorry about all these issues which shouldn't have happened if I had done things correctly. I'll update for real (!) and see how it goes.

Thanks again for your help and time. I appreciated a lot !

And about my Tracy 'theme' : I just use my computer 'negative' mode because I have eyesight problems and I feel better this way. So no leaking, don't worry ;)

 

EDIT : 3.0.62 installed : I can confirm, there is no more a bug with the 2 forms of 'find' statements.

Edited by celfred
Update made !
  • Like 1
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...