Jump to content

Pages Web Service (ServicePages)


ryan

Recommended Posts

  • 3 weeks later...

I just installed this and after installing I get an error.

Error Using $this when not in object context (line 287 of .../site/modules/ServicePages/ServicePages.module)

$this is used in a static method, I wonder that this works on your side? Is this php version related?

Link to comment
Share on other sites

  • 2 months later...
Thanks Soma, I saw you posted a couple of GitHub issues and looks like you are on to something here. I will get into this and fix later this week.

Hello, would like to know is that there is some updates to this module/plugin? Since I found the last commit on Github is still 5 months ago, where can I find the latest version? Thanks

Link to comment
Share on other sites

  • 4 months later...

While working on a ajax driven web service of sorts, I found this exact same problem (on PW 2.3 / PHP 5.3)

When I serve  the page as JSON [ header('Content-Type', 'application/json') ] it throws a 404. This doesn't happen if I send html regularly, but it also doesn't happen if I send jsonp (setting header('Content-Type', 'application/javascript') )

Are these issues related? Or am I doing something very wrong? I couldn't find anything regarding issues setting the header, not even here: http://processwire.com/talk/topic/225-how-to-work-with-ajax-driven-content-in-processwire/?hl=%2Bajax+%2Bdriven

Forget it, I'm a moron  :-[ I'm rusty in PHP, spending my workday as a Frontend Dev... header('Content-Type: application/json') works just fine!

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

Hi Ryan,

Could I make a humble feature request for ServicePages? I'd like it to support subfields in the queries.

For example, I have a template called program that has a PageReference field named regions. Then, I have a template called regions that has a field called code. I made sure that both templates and the fields involved were allowed in the ServicePages config screen.

I'd like to use a selector like this (which works in Batcher and Selector Test modules):

template=program,regions.code=35,title|body*=Export

which in the URL would be:

?template=program&title%7Cbody*=Export&regions.code=35&debug=1

But I'm getting the error:  "Field 'regions_code' is not allowed in queries"

It works fine, of course, if I substitute regions.code for regions=124 (where 124 is the id of the Regions page that has a code value of 35).

It seems like the field sanitizer is renaming regions.code to regions_code instead of sanitizing both the parent and child fields to make sure they're both allowed in queries. 

I'm using Page references for all kinds of metadata, so to efficiently use ServicePages, it would nice not to have to rely on knowing the child page's ID. I could see this being used as 'parent_field'.title quite often.

I guess having "." in a URL parameter name might be problematic - maybe we'd have to use ":" instead?

Thanks for a great module!

-Brent

  • Like 2
Link to comment
Share on other sites

Good suggestion Brent. I'm not at a place where I can test it yet (on mobile), but you might just try changing the $sanitizer->fieldName() on this line to $sanitizer->name() (which allows dots), just to see if it could be as simple as that. 

Link to comment
Share on other sites

  • 3 weeks later...
Now I'm working on the PUT and POST methodes then we have a complete restful solution. But does anyone know if it's possible the call the input settings of a field ? Like required, pattern, ... for a field 

There's a few ways to get at them.This might be the most direct:

$array = $field->getArray();
// or
$array = $field->getTableData();
Link to comment
Share on other sites

  • 2 weeks later...

Hi ryan

I also got the 404 issue and I believe it is to do with how various browsers (maybe?) handle this line:

header('Content-Type', 'application/json; charset=UTF-8');

Changing that to the following, my issues were resolved on Firefox:

header('Content-Type: application/json');

Hopefully that helps others - I guess there may be something "non-standard" or maybe not globally recognised in the line that's in the module - it's all a bit beyond me, but this change resolves it :)

  • Like 3
Link to comment
Share on other sites

I think this may be because the only encoding allowed for JSON is UTF-8, so UTF-8 is implied by the format and a UTF-8 header is technically redundant. Though my understand was that it's still a good idea to specify it. And I'd not be surprised if IE assumed JSON is Windows-1252 if there's no charset header. But if it's screwing up Firefox, that surprises me, but that'd also be a good reason to remove it. Just wondering though since Firefox (or any web browser) is not the intended client for this module, how is Firefox coming into play here (debugging?).

Link to comment
Share on other sites

Yep - I was just using it for debugging purposes to see if I could get it to dish out any data. When it fails it just 404's, so I suppose others are testing in browsers and getting errors maybe.

Link to comment
Share on other sites

Modules don't usually have to think too much about multilanguage, unless they are themselves built to provide additional multilanguage features. I think we need a little more info and perhaps an example of what you are trying to do? Also, is this related to the Pages Web Service module, or a question independent of it?

Link to comment
Share on other sites

Try this: (not tested)

// check the correct url to use on the examples page of the module  
$.getJSON('/someweb.es/service-pages/?title=toby', function(data) {
           alert(data.matches[0].name);
  });
 

Or for iterating all the matches: (also not tested)

$.getJSON('/someweb.es/service-pages/?title=toby', function(data) {
  $.each(data.matches, function(key,val) {
    console.log(key + ' -> ' + val.name); // check the console for this one
  });
});
 

I'm just adapting from here: http://api.jquery.com/jQuery.getJSON/

Edit: tested and corrected a couple of things

  • Like 1
Link to comment
Share on other sites

I tried Diodo's approach but in my case it doesn't work.

I'm getting the correct data with angularjs $htttp.get, but now I get the right data plus the whole html, because I'm using the new foundation4 profile, which allways outputs header, navbar, rightbar and footer because of the config.php file.

How can I get rid off this markup?

Link to comment
Share on other sites

I'm using the new foundation4 profile, which allways outputs header, navbar, rightbar and footer because of the config.php file.

How can I get rid off this markup? 

Add this to your template file:

$useMain = false; 

See the note about this in the /site/templates/_init.php file

  • Like 2
Link to comment
Share on other sites

  • 4 weeks later...

Hello,

I'm coming back on the issue of a request returning a '500 internal error' but working if we add 'debug=1' to it... From what I've understood so far, the remote PHP version not really up to date is the cause, but I must admit it's way over my head (and I can't change the remote version) but here's my situation (and I hope there's a solution) :

- I'm trying to deploy my local site on a remote server

- I found out my 'password hash' problem is coming from the different PHP versions (Up to date on localhost, but 5.3.3... on remote). I managed to solve this.

- My site is making a strong use of the Page Service Module all all my request ended in a 500 internal Server Error.

- I ended up here and found that adding 'debug=1' helped me getting rid of my errors : cool!

- BUT : the response is not in the same form as usual (without debug) and I'm stuck by being unable to treat it accordingly!

I used to do :

      load: function(team) {
        if (team) {
          var url = "service-pages/?template=player&sort=title"+team+"&debug=1"; // Added debug=1 to skip the 500 internal error
          var promise = $http.get(url).then(function (response) {
            return response.data.matches; // USED TO WORK, but no more...
          });
        }
        return promise;

I have no idea how I can solve this issue... Just in case you wonder where my code is from : it's inside an AngularJs service.

Thank you for your help ;-)

Edit 01 : Well, I re-read the whole topic trying to understand... and I tested Pete's answer about headers and... it worked, but I really don't know why... Just so you know, I use Firefox 25. I'm worried to know if it'll work with other browsers...

If it can help others : I changed line 236 in the ServicePages.module file :

Original line :

else header('Content-Type', 'application/json; charset=UTF-8');

New line :

else header('Content-Type: application/json');

Anyway : thanks Pete! And if someone can take the time to explain why this manipulation is needed, I'd appreciate!

Still thinking : if other browsers need different headers, would there be a way to specify this in the same place in the file (like if browser is IE, then send such headers, if it's Firefox, send this one...)?

Edit 02 : Me again... I keep reading about those headers... and tried a couple of things and here's what I got

I just changed syntax in line 236 mentionned above :

Doesn't work :

else header('Content-Type', 'application/json');

WORKS !

else header('Content-Type: application/json; charset=UTF-8');

I checked the PHP manual about the header function and I thought maybe the second parameter in the original line in the module is interpretated as the 'replace' parameter they talk about in the documentation... It it makes sense maybe the line should be changed in the module? I actually have NO idea if what I'm saying makes sense. Maybe all this is obvious to everyone here, but I kept stuck on that for a few hours today ;-)

Link to comment
Share on other sites

You are absolutely right. Not sure how I managed to implement a header() call with two arguments like that, or how on earth it was working before, anywhere. But it should be the single argument version of the header() call. I've fixed it and pushed in the update. I'm also leaving out the charset=UTF-8 as I've read elsewhere that it's implied with a JSON header, so kind of redundant. Thanks for finding this. 

Link to comment
Share on other sites

  • 3 weeks later...

I'm using TextLanguage and TextareaLanguage fieldtypes for a multi-lingual site. When using Pages Web Service, the resulting json data only ever includes the default language value for a multilingual field. I think this is what davydhaeyer was asking about (above)...

Would it possible to extend Pages Web Service to support multiple language fields? 

Ideally I think it should return all languages in the json response. It would also be great to be able to specify a language in the request, which would limit the response to one language – which would flatten/simplify the json response in that case (as it's doing now, but it's only doing it for the default language).

-Brent

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
×
×
  • Create New...