Skip to content Skip to navigation

Blog

Caryl Westerberg Posted by Caryl J Westerberg on Tuesday, May 31, 2016 - 4:54pm

DrupalCon (Drupal Conference) 2016 marked the 3rd DrupalCon that I attended. With Drupal 8 released, I felt it was time to go to the conference and kick the tires.

Held in historic New Orleans, I not only learned more about Drupal 8, but I learned about the beignets, cemeteries, and handgrenades. But that’s for another story.

Drupal 8 brings a greater emphasis on “headless” architectures where the front-end that the user sees may be decoupled from a Drupal back-end. At this conference I focused on learning what we can do with a decoupled Drupal front-end. Here are my highlights from Drupalcon 2016:

Presentation Framework: Reveal.js

Want to ditch PowerPoint slides and move to something online and mobile responsive? Reveal.js  is a presentation framework used deliver many DrupalCon presentations. This was not a presentation itself, but rather, a technology, where, using HTML presentors can deliver rich presentations with lots of features and flexibility. If you want to try the fully-featured visual editor check it out at http://slides.com.

Amazing User Experiences with Drupal and Ember

by Edward Faulkner

Link to session

Want a richer experience for your site? It turns out that Ember provides a software development kit (SDK) to help you build out ambitious applications. In this session Faulkner first demonstrated how to integrate Drupal with Ember then demonstrated some amazing inter-page animations, Service Worker-driven offline capabilities, and in-site authoring tools with instant preview across multiple device sizes.

Offline-capable, decoupled Drupal 8 with React.js and React Native

By Mikkel Høgh and Dick Olsson

Link to session

People such as doctors travelling to remote areas without internet still need access to website data. To address this, they need websites to be available offline on their devices.  In this session Høgh and Olsson show us how they used React.js, PouchDB, and RELAXed to load an entire website onto a device such as a phone and make it fully capable offline.

Related links

Demystifying AJAX Callback Commands in Drupal 8

By Michael Miles at Genuine Interactive

Link to session

Suppose you want to use existing data to provide more functionality on an existing page on your site. In this session Miles dove into the internals of Drupal’s Ajax framework and demonstrated how you can extend an existing Drupal page, replace links with Ajax calls. Then when you click on the link, instead of navigating to the linked page, the current page expands to display the data from the linked page.

Related links

http://mike-miles.com/sessions/drupalcon-d8-ajax/#/ - Slides

Debugging, Profiling, & Rocking Out with Browser-Based Developer Tools!

By Mike Herchel at Lullabot

Link to session

Chrome’s Developer Tools has an amazing number of tools, options, and shortcuts for exploring the underpinnings of a website. In this session Herchel took us on a tour of these clever and timesaving tools. If you do any serious front-end development, learning these tools this is a must.

Related links:

BigPipe

By Wim Leers and Fabian Franz

Link to session

In this session Leers and Franz explore the question: How can Drupal start sending page data early? To give the perception of improved performance, users will see the page beginning to render earlier rather than seeing a blank white screen. Using caching, BigPipe sends page information early, and begin displaying the page before Drupal has completely finished rendered the page.

Related Link

https://www.drupal.org/project/big_pipe

JSON Powered Forms in Drupal

By Travis Tidwell and Randall Knutson

Link to session

As we support more devices, interfaces become more diverse. We cannot expect Drupal to support these interfaces. Travis Tidwell and Randall Knutson explained their approach to providing forms that are dynamic JavaScript renderings of JSON based schemas. With this JSON, the client can render the form for specific devices.

Related links:

Looking forward

The idea of decoupling Drupal from the front end is not new in Drupal 8. In fact many of these technologies will work on your Drupal 7 site, albeit less support from Drupal and more work for you. To learn more about decoupling Drupal, check out this post by Dries BuytaertI encourage you to keep an eye on the decoupled or headless Drupal conversation, and check out the videos for these sessions!

 
Brittany Cripe Posted by Brittany Cripe on Tuesday, May 17, 2016 - 11:02am

Creating the Cardinal at Work website was an opportunity for UHR to enhance the employee experience at Stanford. Our primary focus was consolidating and reorganizing content from 12 employee websites into a single online destination.

Now, faculty, staff and retirees can access information about benefits and rewards, career development, management, and connection opportunities in one convenient location. The site is also enhanced with features such as advanced search, a resource library, navigation by role, task and topic, and much more.

As with any large-scale initiative, getting to the finished product was no easy feat. From start to finish the process took nearly two years and more than 2,100 hours of technical and content development work to complete. Needless to say, we learned A LOT in the process and have compiled some of these “Lessons Learned” in case they may help others embarking on the website redesign journey.

So without further ado, here are some of the lessons we learned from launching a supersite.

#1: Have clearly defined goals and revisit them often

Ensure that you have clear goals for your site and that they are agreed upon by your key stakeholders. Refer back to your goals often, especially when making decisions, and don’t be afraid to remind stakeholders of these goals when they request new content and features that could potentially derail the project. This helps keep your project (and budget) in check. Your trusty partners at SWS can help remind you of your goals when you start to veer off course.

#2: Know your audience well, and remember their needs

Knowing our audience helped us make key content, navigation and technical decisions. Through research, surveys and focus groups we developed an understanding of the online behaviors and communications preferences of Stanford employees which helped us tailor the website to fit their needs. As part of this process, we also developed a “communications manifesto” which we referred to often. Part of that manifesto is that Stanford employees are “intelligent, influential, knowledgeable—and overloaded with information.” This served as a reminder to ensure our content was transparent and thorough while also being crisp, tight, and actionable.

#3: Develop a voice and style guide

Ensuring that content is written in a single voice and style was a top priority for us. Our old sites were completely fragmented in this regard. Because we have about a dozen or more staff members authoring content, we recognized that consistency and cohesiveness in voice and style could crumble quickly. Therefore one of our first priorities was developing a style guide and ensuring our writers had easy access to it. This was made possible by our friends at SWS who created an online version of the guide, which lives behind the login of the Cardinal at Work website.

#4: Use a data-driven approach

Using analytics from our old websites was key in determining content priorities and the overall structure of the new site. And, we validated all our decisions through several rounds of user testing at various stages throughout the project.

#5: Finalize content outside of Drupal

As much as possible, finalize content in Word or Google documents before putting it into Drupal. At the very least, finalize page names and navigation labels outside of Drupal. For us, we made the mistake of changing our page names and navigation labels all the time. Therefore URLs continuously were broken and we drove our web producer crazy in the process!

#6: Develop a system for organizing site feedback

When it comes time to solicit feedback from department stakeholders, develop a system to organize and track the feedback. We created a simple Excel document that included the date, name of person reviewing, URL of the page in question, page section and their comments. We also included a column for who’s responsible for making the change and the status (in progress, complete, etc.). This simple system helped keep things organized and streamlined. It also provided a historical record for WHY something was done.               

#7: Provide frequent updates to stakeholders

Keep stakeholders informed of the status throughout the entire development process. We found that lunchtime “show and tells,” email updates and FAQs worked well to keep our unit informed of the site progress and important action items leading up to launch.

#8: Find a “photo guru”

A photo guru is a person on your team who is responsible for selecting and formatting all the imagery on the site. Having a singular person (or two) responsible for imagery helps ensure variety and quality in photos and avoids duplication.

#9: Working with web designers: focus on the “why,” not the “how”

Let web designers do what they do best. If something isn’t working for you, tell them WHY it’s not working rather than HOW to fix it.

#10: Find a pair (or two) of fresh eyes

Before the site goes live, engage a contractor or team member who has not been involved, to edit and comb through the site with fresh eyes. You’ll be amazed at what they find!

#11:  One-on-one training and frequent communications with web editors

We have found that hands on, one-on-one trainings with department web editors are highly effective. Be sure they have access to the online style guide. Schedule monthly check-in meetings with web editors to provide demos and share updates.

#12:  Soft launch first

Schedule a “soft” launch about a week before you start promoting your new website. This allows time to fix any last minute bugs or unanticipated issues. Announce the soft launch to select audiences and solicit their feedback and input.

#13: Wait and see

After launch, don’t panic when feedback starts to come in. Watch for trends and give the audience time to get used to the new website before you make major changes. And, when it comes time to make changes, be just as thoughtful and strategic as you were during the development phase.


These are just a few of the many lessons we learned throughout the process of building the Cardinal at Work website. If you have questions or would like to know more, feel to contact us. Best of luck as you embark on your website journey!

Brittany Cripe, Senior Communications Specialist, blcripe@stanford.edu

Mark Nakamura, Web Producer, marknaka@stanford.edu

Marie Vasquez, Communications Manager, mariev@stanford.edu

 

 

Cynthia Mijares Posted by Cynthia Mijares on Thursday, May 12, 2016 - 9:06am

Want to hide or move the WebAuth login block on your website? On Stanford Sites the login block is in the left sidebar by default giving the administrator easy access to log in and make changes to their website. As an administrator you have the option to move this block to a different region or completely hide it.  Let's talk about both options and their ramifications.

If you have multiple people collaborating on your site, you may choose to keep the WebAuth Authentication block visible somewhere on the page.

If you are the only person who needs to make changes to the website or you do not want to give anonymous visitors the option to log in, you can choose to hide the WebAuth Authentication block.  You can still log in via WebAuth just go the the URL and add /user to access the log in screen. For example: Go to https://people.stanford.edu/SUNETID and change the path to https://people.stanford.edu/SUNETID/user.  You will see the User account page where you can click on the Log in with WebAuth link.

User account log in screen

Move or hide the WebAuth Login block

  1. Click the Log in with WebAuth.
  2. From the Admin menu bar, navigate to Structure > Blocks.
  3. Locate the WebAuth Authentication block in the First sidebar region.
  4. Use the double-pointed arrow to drag this block to another region or use the drop-down list to select a region. To hide the block, select - None - from the drop-down list or drag it to the Disabled section.
  5. Then scroll to the bottom of the page and click Save blocks.

WebAuth Authentication

Posted in:
Shea McKinney Posted by Shea Ross McKinney on Monday, April 11, 2016 - 10:20am

There are times where I curse open source software but those times are far outweighed by the times that I am reminded why I love it so much.

Normally my blog posts are on the technical side because that is where I feel safe and comfortable writing in a public space but I felt compelled, okay, urged by the boss and team, to write about a moment that I gushed about during a recent staff meeting.

The week started off as a bug fix week, a sprint to tackle long-standing or annoying bugs that are in our sites and products. One peculiar bug was on our Subsite Feature: when an anonymous user first landed on the subsite node after a cache clear, they would be presented with the default (wrong) theme instead of an alternate theme. Before I even began, one of my workmates (John Bickar) pointed me to a blog article that clearly outlined the problem I was seeing. This was a very timely article as it was fresh off the press. Looking in to the issue I confirmed that, indeed, the issue described in the article was what I was seeing.

This spurred a major refactor in to how the module worked, but that is beside the point. If it wasn't for the fact that someone else wrote an article about the problem and solution, and my workmate hadn't passed it along, I would have spent many more hours in my debugger trying to figure out the cause of the issue. Yay open source!

Once the module was refactored to get around the issue with using hook_custom_theme() and loading entities, I passed off the final code to my other workmate, Greg Garvey, who did the majority of the heavy lifting of the refactor, to test to see if the solution was complete.

His testing came back negative; the issue was still happening in his environment.

Back and forth we went trying to figure out why he was still seeing the issue and why I was not. Through a bit of chance, we found out that another contributed module on his environment (subpathauto) had the same issue in it. Boo open source! Having already dealt with the issue once, I took it upon myself to fix the issue in the contributed module and posted a patch, which I hope will be adopted soon. Yay open source!

It may have been an unlikely path in which the patch came back to the subpathauto project but it really highlights the awesomeness that is open source and the Drupal community. Someone with the exact problem I faced took the time to write about it. Someone in my working group shared that information with me, and when I found the issue in another project I was able to contribute my knowledge back to it. I find times like these powerful and what will give Drupal the long term adoption we hope for.

Posted in:
Photo of John Bickar Posted by John Bickar on Friday, April 1, 2016 - 12:01am

The modern web developer has a variety of markup languages available for use in different contexts: XML, HTML, YAML, Markdown - the list goes on and on. Yet each has its limitation(s), whether that be performance, readability, or ease-of-use.

That all changes today with the introduction of the Syntactically Accurate Markup Language (SAML).

SAML is a human-readable markup language designed to be used in a variety of contexts - web, mobile, APIs, and so forth.

As the modern web moves away from desktop browsers and more towards "content anywhere, on any device", we need a markup language that supports that end.

The Premise of SAML

SAML is a straightforward, human-readable language. There are no tags, no attributes, no esoteric syntax. Words are what they mean; a new line is a new line; and punctuation is what it says it is.

To write SAML, you simply write.

SAML Example

As a concrete example, let's look at a list of items in SAML:

Apple
Orange
Banana
Pear
Watermelon

Now, let's compare the same list in HTML:

<ul>
<li>Apple</li>
<li>Orange</li>
<li>Banana</li>
<li>Pear</li>
<li>Watermelon</li>
</ul>

As you can see, SAML is clean, forthright, and syntactically accurate.

Special Symbols in SAML

As SAML is syntactically accurate, it supports all of the usual punctuation symbols. There are no hidden meanings.

Below is a summary of commonly-used punctuation marks and their equivalent in SAML:

Text Punctuation Mark SAML Equivalent
. .
, ,
! !
? ?
¿ ¿
¡ ¡
# #

 

Advantages of SAML

  1. Readability: In SAML, words and punctuation are used to create sentences. Sentences are used to create paragraphs. It's that simple.
  2. Performance: In the list example above, SAML is 37 bytes, compared to 92 bytes for HTML. That's a 248% increase in performance.
  3. Security: No Bobby Tables in SAML; a semicolon is just a semicolon.
  4. Device-independence: SAML is device-agnostic. Desktop browser, tablet, mobile phone, app, pen-and-paper - SAML works on them all.
  5. Backwards-Compatibility: SAML is compatible with all historical web browsers (only tested as far back as Mosaic 0.5) and mobile devices.
  6. Multilingual: SAML is language-independent. You can write SAML in any language you wish.

SAML Sounds Great - What Now?

At Stanford University, we are dedicated to finding solutions to big challenges. At Stanford Web Services, we believe in the power of open source, and releasing early and often.

Therefore, today we are announcing the open-source release of SAML 0.1. Learn more at discoversaml.org.

Posted in:
Caryl Westerberg Posted by Caryl J Westerberg on Friday, March 4, 2016 - 3:55pm

We are excited to announce that registration and session proposals are now open for Stanford Drupal Camp 2016!

Register now for the seventh Annual Stanford Drupal Camp April 1-2, 2016 at the Stanford Law School.

https://drupalcamp.stanford.edu/user/register

Drupal Camp is a great opportunity for the Stanford Drupal community to come together and share new approaches, best practices for the web, and love of Drupal. The schedule includes great sessions for those new to the web and Drupal all the way to advanced users and plenty of opportunities to network with colleagues.

We will have tracks for web content strategy, user experience and design, operations and development (DevOps), and building sites for research and academia.

As always, it’s free!

Once you've registered, you are invited to propose a session. In the right sidebar, click on Propose a Session!

If you have any questions, please contact drupalcamp@lists.stanford.edu

Happy Drupalling, and look forward to seeing you in April!

Posted in:
Sara Worrell-Berg Posted by Sara Worrell Berg on Tuesday, February 23, 2016 - 4:49pm

University IT will perform maintenance on the Stanford Sites Drupal hosting service on the following date:

This maintenance requires switching Stanford Sites to using its secondary database server in preparation for upcoming maintenance on the university's network. Planned changes should result in improved stability and faster performance for all websites hosted on Stanford Sites. This maintenance does not include Drupal core application or module updates.

Website owners should avoid content or configuration changes to their websites hosted on the Stanford Sites Drupal hosting service between 4:45-5:30 AM on Thursday, February 25. A brief loss of connection to the database server can be expected, though there should be no data loss or extended downtime.

Monitor https://uitalerts.stanford.edu for more information.

If you experience issues with your website(s) hosted on Stanford Sites, please submit a HelpSU request. We will respond as soon as possible.

Thanks for using Stanford Sites!

Posted in:
Jamie Posted by Jamie C. Tsui on Friday, February 12, 2016 - 12:25pm

Stanford Web Services serves a diverse set of clients throughout Stanford University, ranging as large as schools to as small as individual labs. With over 200 active or completed website projects, and an average of 18 new project inquiries per month, we needed to implement a Customer Relationship Management system to track all of our operational data and communications.

Which CRM?

Last year we evaluated 7 different CRMs, including: Insightly, SalesForce, Zoho, Sugar CRM, HubSpot, RedHen, and Podio. After analyzing each of the options through an evaluation matrix based on our needs, we settled on Podio for our team. It has now been over 7 months since we’ve migrated all of our data from disparate systems into Podio, and the reception has been very positive across all roles in the team. We were able to consolidate various types of information from Basecamp, Google Docs/Sheets, Excel files, email, mailing lists, and even information that only existed in our staff’s memory.

Importing and Setting Up Your Data

One of the critical requirements for adding a CRM to our operations was its ease of data import and export. Podio, at its core, can be thought of as a UI on top of a relational database, so we found it extremely flexible and customizable for our needs. It’s quick and simple to import and export data in Excel format. We set up several “apps” for each of our types of data: an “app” is similar to that of a Content Type in Drupal, though simplified. We have apps for our leads, organizations, projects (completed and in progress), website launches calendar, help tickets, products (we have several product offerings, including the Jumpstart product line), potential deals (new inquiries), website theme information, vendor contacts, and more.

Connectivity and API

Using Podio’s “Email API”, we were able to easily integrate a number of other systems to feed data into Podio. Although Podio has built-in support for webforms, we use Qualtrics to create web forms with question display logic and email triggers to customize the data that gets fed into Podio (such as for help tickets or new project inquiries). We’ve also used ZenDesk’s triggers to pass help ticket information from one of our partners to Podio.

By having all of our operational data in one system, we were able to improve our operations across the board, from the intake level all the way through to the support level. We can take a look at an organization’s listing and easily see all of our active and completed projects with them, their related help tickets, a list of new project inquiries from them, as well as the potential value of those new projects.

The inbox is not where you store communications

Another one of the primary goals for implementing a CRM was to record communications more visibly and permanently as opposed to in an individual’s email or via a mailing list. Within each of these items in Podio, such as a single project, or a single help ticket, Podio allows users to add comments and attachments via an “activity stream”. This feature essentially improves coordination and communication within the team: such as if someone needs to take over a deal consultation from another team member and wants to read all the past communications with that client. To do this, our team member would simply CC or BCC the “Email To Item” email address provided by Podio for that specific item. This process also ensures information retention for the team. Changes to fields within an item are also tracked in the activity stream, allowing us to see who made the change and when.

A single point of reference

Podio serves as first point of reference for information: from there, we can link out to a project’s relevant Harvest listing, JIRA project, Basecamp listing (if applicable), as well as links to a project’s development and production site URLs. Since implementing it with our operations, it has saved countless hours of searching and coordination, as well as improved communications and information awareness within our team.

Have you looked into CRMs for your team, or do you use one already? How has your experience been? What are your favorite features from your CRM?

Photo of John Bickar Posted by John Bickar on Tuesday, February 2, 2016 - 8:25am

In November, 2015, the Stanford Web Services team got to dive into Drupal 8 during a weeklong sprint. I was excited to look at the RESTful web services that Drupal 8 gives out-of-the-box; what follows is my documentation of the various types of requests supported, required headers, responses, and response codes.

This is not intended to be an exhaustive documentation of RESTful web services in Drupal 8. However, I have pulled information from various posts around the Web, and my own experimentation, into this post.

A REST client application (e.g., Paw for Mac OS X) is extremely handy for experimenting with RESTful web services in Drupal 8.

Contents

  1. Resources
  2. GET Request
  3. POST Request
  4. DELETE Request
  5. PATCH Request

Resources

GET Request

The GET request is the simplest, and requires no authentication (if permissions are configured to allow anonymous users to "Access GET on Content resource"). Just send a GET request to the node path and add a _format=hal_json URL parameter.

More documentation available at drupal.org.

Request

<a href="https://example.com/node/<nid>?_format=hal_json">https://example.com/node/<nid>?_format=hal_json[/geshifilter-code]

Response

200 OK

{
  "_links": {
    "self": {
      "href": "<a href="https://example.com/node/8?_format=hal_json"
">https://example.com/node/8?_format=hal_json"
</a>    },
    "type": {
      "href": "<a href="https://example.com/rest/type/node/article"
">https://example.com/rest/type/node/article"
</a>    },
    "<a href="https://example.com/rest/relation/node/article/uid":">https://example.com/rest/relation/node/article/uid":</a> [
      {
        "href": "<a href="https://example.com/user/3?_format=hal_json",
">https://example.com/user/3?_format=hal_json",
</a>        "lang": "en"
      }
    ],
    "<a href="https://example.com/rest/relation/node/article/revision_uid":">https://example.com/rest/relation/node/article/revision_uid":</a> [
      {
        "href": "<a href="https://example.com/user/3?_format=hal_json"
">https://example.com/user/3?_format=hal_json"
</a>      }
    ],
    "<a href="https://example.com/rest/relation/node/article/field_tags":">https://example.com/rest/relation/node/article/field_tags":</a> [
      {
        "href": "<a href="https://example.com/taxonomy/term/2?_format=hal_json",
">https://example.com/taxonomy/term/2?_format=hal_json",
</a>        "lang": "en"
      }
    ]
  },
  "uuid": [
    {
      "value": "a57f21eb-a4fe-4c04-8507-7a9cb1255834"
    }
  ],
  "type": [
    {
      "target_id": "article"
    }
  ],
  "langcode": [
    {
      "value": "en",
      "lang": "en"
    }
  ],
  "title": [
    {
      "value": "Test Article 2",
      "lang": "en"
    }
  ],
  "_embedded": {
    "<a href="https://example.com/rest/relation/node/article/uid":">https://example.com/rest/relation/node/article/uid":</a> [
      {
        "_links": {
          "self": {
            "href": "<a href="https://example.com/user/3?_format=hal_json"
">https://example.com/user/3?_format=hal_json"
</a>          },
          "type": {
            "href": "<a href="https://example.com/rest/type/user/user"
">https://example.com/rest/type/user/user"
</a>          }
        },
        "uuid": [
          {
            "value": "46a5a516-2d00-41fa-b300-f0342bec87f5"
          }
        ],
        "lang": "en"
      }
    ],
    "<a href="https://example.com/rest/relation/node/article/revision_uid":">https://example.com/rest/relation/node/article/revision_uid":</a> [
      {
        "_links": {
          "self": {
            "href": "<a href="https://example.com/user/3?_format=hal_json"
">https://example.com/user/3?_format=hal_json"
</a>          },
          "type": {
            "href": "<a href="https://example.com/rest/type/user/user"
">https://example.com/rest/type/user/user"
</a>          }
        },
        "uuid": [
          {
            "value": "46a5a516-2d00-41fa-b300-f0342bec87f5"
          }
        ]
      }
    ],
    "<a href="https://example.com/rest/relation/node/article/field_tags":">https://example.com/rest/relation/node/article/field_tags":</a> [
      {
        "_links": {
          "self": {
            "href": "<a href="https://example.com/taxonomy/term/2?_format=hal_json"
">https://example.com/taxonomy/term/2?_format=hal_json"
</a>          },
          "type": {
            "href": "<a href="https://example.com/rest/type/taxonomy_term/tags"
">https://example.com/rest/type/taxonomy_term/tags"
</a>          }
        },
        "uuid": [
          {
            "value": "14bd6eeb-f0f1-4fd1-b200-e27246318b7c"
          }
        ],
        "lang": "en"
      }
    ]
  },
  "status": [
    {
      "value": "1",
      "lang": "en"
    }
  ],
  "created": [
    {
      "value": "1446588457",
      "lang": "en"
    }
  ],
  "changed": [
    {
      "value": "1446589578",
      "lang": "en"
    }
  ],
  "promote": [
    {
      "value": "1",
      "lang": "en"
    }
  ],
  "sticky": [
    {
      "value": "0",
      "lang": "en"
    }
  ],
  "revision_timestamp": [
    {
      "value": "1446588457"
    }
  ],
  "revision_translation_affected": [
    {
      "value": "1",
      "lang": "en"
    }
  ],
  "default_langcode": [
    {
      "value": "1",
      "lang": "en"
    }
  ],
  "comment": [
    {
      "status": "2",
      "cid": "0",
      "last_comment_timestamp": "1446588457",
      "last_comment_name": null,
      "last_comment_uid": "3",
      "comment_count": "0",
      "lang": "en"
    }
  ]
}

Authentication

POST, DELETE and PATCH requests require a CSRF token, as well as HTTP Basic Authentication (with a user's Drupal user name and password).

Get the token at <a href="https://example.com/rest/session/token">https://example.com/rest/session/token[/geshifilter-code]

POST Request

Request

<a href="https://example.com/entity/node">https://example.com/entity/node[/geshifilter-code]

Headers

Header Name Header Value
X-CSRF-Token (token from rest/session/token)
Authorization Basic (hashed username/password)
Content-Type application/hal+json

Body

{
  "_links": {
    "type": {
      "href": "<a href="https://example.com/rest/type/node/article"
">https://example.com/rest/type/node/article"
</a>    }
  },
  "title": {
    "value": "Test Article 2"
  },
  "type": {
    "target_id": "article"
  }
}

Response

200 OK

DELETE Request

Request

<a href="https://example.com/node/<nid>">https://example.com/node/<nid>[/geshifilter-code]

Headers

Header Name Header Value
X-CSRF-Token (token from rest/session/token)
Authorization Basic (hashed username/password)

Response

204 No Content

PATCH Request

Use the PATCH method to update an existing entity.

Request

<a href="https://example.com/node/<nid>">https://example.com/node/<nid>[/geshifilter-code]

Headers

Header Name Header Value
X-CSRF-Token (token from rest/session/token)
Authorization Basic (hashed username/password)
Content-Type application/hal+json

Body

{
  "_links": {
    "type": {
      "href": "<a href="https://example.com/rest/type/node/article"
">https://example.com/rest/type/node/article"
</a>    }
  },
  "nid": {
    "": {
      "value": "8"
    }
  },
  "type": {
    "target_id": "article"
  },
  "promote": {
    "value": "1"
  },
  "body": {
    "": {
      "value": "<p>foo bar baz</p>",
      "lang": "en"
    }
  }
}

Response

204 No Content

Posted in:
Cynthia Mijares Posted by Cynthia Mijares on Thursday, December 17, 2015 - 8:00am

2015 has been amazing! Big thanks to all of our wonderful and devoted colleagues around the university and in the community. We wish you happy holidays over the winter break, and we'll see you in 2016!

 

Team photo

Posted in:

Pages

Subscribe to Stanford Web Services Blog