I am not a drupal dev, and i know next to nothing of php specifically. That said, I am developing a new interface for an existing drupal website and we will continue to use drupal in headless mode using the rest api while we migrate to a better long term solution.
Exposing custom content types be pretty straightforward for the most part, but one aspect is giving me a headache: it seems impossible to expose the list of allowed values in a list field (e.g. list of decimals, integers or text). Ideally, there would be a way to query the drupal api for a given field name, returning a list of possible values for that field.
The closest I've gotten is through the entity rest extra module found here.
but while it exposes a ton of info on the fields, even default value for the list field, the allowed values are not there.
Is there a way to expose the allowed values list in the restful api?
Since the module I found is so close to what I need, would it be easily implemented by custom patching my drupal php code? where should I look for clues?
thanks in advance
Related
I've looked around the site to see if there are any people who have changed the CKAN API interface so that instead of uploading documents and databases, they can directly type onto the site, but I haven't found any use cases.
Currently, we have a page where people upload data sets through excel forms that they've filled out, but we want to make it a bit more user friendly by changing the API so that they can fill out a form on the page rather than downloading the template, filling it out and then uploading it.
Does CKAN have the ability to support this? If so, are there any examples or use cases of websites that have use forms rather than uploads?
This is certainly possible.
I'm not aware of any existing extensions that provide that functionality, but you can check the official list of CKAN extensions if there's anything that fulfills your needs.
If there is no existing extension that suits you then you could write your own, see the extension guide for details on how to do that.
Adding an API function to CKAN's API is possible, but probably not what you want in this case: the web UI usually does not interact with CKAN via the API but via Flask/Pylons controllers. Hence, you would add your add controller which first serves your form and then processes the submitted inputs.
You can take a look at the ckanext-pages extension, which does exactly that (for editing static pages instead of datasets, but your code would be similar).
I've written a simple module using the Drupal 7 forms API which adds a block to Drupal which can then be used on multiple nodes.
I'm a bit lost as to the best way to customise some of the values in (hidden) form fields based on where it's been included.
E.g. the module on the /articles/ may need to have a hidden value to say which mailing list they're signing up to, and the same form on /petitions/ may need a different value.
Is there a more elegant way to do this than using form_alter hooks?
I am building a web app that pulls data through the Core Reporting Api v3 from Google. I am using the client PHP library offered by Google.
I am currently trying to specify a page and retrieve its pageviews for a time range. Every other seems to be working okay except for the fact that if a specfy a filter with ga:pagePath==http://link/uri then I get 0 all the time no matter the time range.
I think the problem is got to do with the setting of value for this pagePath. I want to have spearate data for the desktop version of the site and the smartphone version denoted by s. subdomain
Can anyone hint me on some tips and or tricks to use to get the required data?
Example URL:
http://domain.com/user/profile/id/1
http://s.domain.com/user/profile/id/1
Thanks in advance!
for the the default implementation of Google Analytics, ga:pagePath doesn't include the scheme or hostname so in your case you'd actually want to filter using ga:hostname and ga:pagePath together.
I suggest you use the Query Explorer to build your queries and get familiar with what will work. You can also use this tool to at least get a sense for what type of data the ga:pagePath and ga:hostname dimensions return before trying to filter on them. Finally, once you have the query you want, you can easily get the exact Core Reporting API query by clicking on the Query URI button.
Also check out the Combining Filters section of GA API docs.
So if you want filter on ga:pagepath for domain.com and s.domain.com separately you could do something like
filters=ga:pagePath==/user/profile/id/1;ga:hostname==domain.com
filters=ga:pagePath==/user/profile/id/1;ga:hostname==s.domain.com
I did not realise the power of REST until I started using scaffolds in rails. This makes life so simple. Now everytime I try to develop a web application I only think of those 6 verbs. But I have a doubt. How is search related to REST.
Basically the search page which contain a form for the user to input a search term.
which verb does this come under? Is it list??
and what does the search results come under? show?
Search is GET on the collection with some fancy attributes:
GET /articles?q=RESFful+Architecture&in_title=1
Something like that.
There are plenty of resources on the subject, check out Handling arbitrary actions, on ajaxpatterns, for example.
If I understand what you are saying properly, the search page wouldn't be a part of the rest service, but would submit to it.
The search results would be a list of whatever the first class object you had defined was. The Uri would describe the resource that was being displayed.
Retrieving resources is always done with a GET
eg: GET /cars?term=hyundai+green
I'm currently using the Jira SOAP interface within a C# (I suppose the language used here isn't terribly important).
Basically, I'm creating an API and a Winform that wraps some of the functionality of the soap service so that our Devs can programmaticly add bugs when something goes wrong in our application.
As part of this, I need to know the custom field IDs that are in use in Jira, rather than hardcoding them (as they are still prone to the occasional change) I used the GetCustomFields() method in the jira-rpc api then filtered it, so that all the developer needs to know is the name of the field, then the ID is filled in for them automagically.
This all works fine, but with one quite important proviso: that you login to the SOAP/RPC service as a user with administrative privaliges.
The Jira documentation indicates that the soap/rpc service follows the usual workflows and security schemes, however I can't find anything anywhere that would appear to remove this restriction on enumerating custom fields (and quite why in any instance you would want someone to HAVE to be an administrator to gain this access, especially as the custom field id's tend to be in Jira's HTML source is beyond me)
Does anyone know if I've missed a setting somewhere? Or if there is some sort of work-around for this, short of hardcoding the custom field id's?
Or is this a case of having to delve in to Jira's RPC plugin and modifying the source for it in order to give me the functionality I require?
Cheers
Edit for the sake of google/posterity
Wow, all this time on, and it looks like Atlassian still haven't changed this behavior.
Worked around this by creating a custom dictionary that logs in as an administrative user, grabs the custom fields and then logs out. Not ideal, but it should work 'til atlassian change things
You're not missing anything - there's no way to get custom fields via standard SOAP API.
In JIRA Client, we learn about custom fields in two ways:
We download issues via RSS view of the issue navigator, or via XML representation of a specific issue. If a custom field is set for an issue, the XML will have its id, class and value (values).
From time to time we inspect the content of IssueNavigator search page - looking for searchers for the custom fields. Screen-scraping the HTML gives us not only ids of the custom fields but also possible values for enum fields.
This is hackery, of course, and it may go wrong, so a good API would have been a lot better.
In your case, I can suggest two solutions:
Create your own SOAP (or REST) remote API plugin that will give you just that info that you miss from the standard API. Since you're seemingly in control of your JIRA, you can install anything there.
Screen-scrape the "New Bug" page for the project and type of issue you need to submit. You'll get all the info - fields, options, default values, which field is required.