Turning complexity into clarity.

Full stack web developer for Wonderment on WordPress - Upwork

WordPress Work From UpWork - Wed, 02/13/2019 - 22:47
About us:
We are a wellness training and travel company going through a rebranding phase.

What we're looking for:
An experienced full stack developer to help edit on our current WordPress website to balance out the new content based around these rebranding efforts.

We have all of the content and photos ready and are looking for someone to make these changes within a week.

In your proposal, please share a brief summary of your experience, your hourly rate, and tell us about a recent web development project you worked on.


Posted On: February 14, 2019 02:11 UTC
Category: Web, Mobile & Software Dev > Web Development
Skills: Web Design, WordPress
Country: United States
click to apply

Drupal blog: Headless CMS: REST vs JSON:API vs GraphQL

News from Planet Drupal - Wed, 02/13/2019 - 19:52

This blog has been re-posted and edited with permission from Dries Buytaert's blog.

The web used to be server-centric in that web content management systems managed data and turned it into HTML responses. With the rise of headless architectures a portion of the web is becoming server-centric for data but client-centric for its presentation; increasingly, data is rendered into HTML in the browser.

This shift of responsibility has given rise to JavaScript frameworks, while on the server side, it has resulted in the development of JSON:API and GraphQL to better serve these JavaScript applications with content and data.

In this blog post, we will compare REST, JSON:API and GraphQL. First, we'll look at an architectural, CMS-agnostic comparison, followed by evaluating some Drupal-specific implementation details.

It's worth noting that there are of course lots of intricacies and "it depends" when comparing these three approaches. When we discuss REST, we mean the "typical REST API" as opposed to one that is extremely well-designed or following a specification (not REST as a concept). When we discuss JSON:API, we're referring to implementations of the JSON:API specification. Finally, when we discuss GraphQL, we're referring to GraphQL as it used in practice. Formally, it is only a query language, not a standard for building APIs.

The architectural comparison should be useful for anyone building decoupled applications regardless of the foundation they use because the qualities we will evaluate apply to most web projects.

To frame our comparisons, let's establish that most developers working with web services care about the following qualities:

  1. Request efficiency: retrieving all necessary data in a single network round trip is essential for performance. The size of both requests and responses should make efficient use of the network.
  2. API exploration and schema documentation: the API should be quickly understandable and easily discoverable.
  3. Operational simplicity: the approach should be easy to install, configure, run, scale and secure.
  4. Writing data: not every application needs to store data in the content repository, but when it does, it should not be significantly more complex than reading.

We summarized our conclusions in the table below, but we discuss each of these four categories (or rows in the table) in more depth below. If you aggregate the colors in the table, you see that we rank JSON:API above GraphQL and GraphQL above REST for Drupal core's needs.

REST JSON:API GraphQL Request efficiency Poor; multiple requests are needed to satisfy common needs. Responses are bloated. Excellent; a single request is usually sufficient for most needs. Responses can be tailored to return only what is required. Excellent; a single request is usually sufficient for most needs. Responses only include exactly what was requested. Documentation, API explorability and schema Poor; no schema, not explorable. Acceptable; generic schema only; links and error messages are self-documenting. Excellent; precise schema; excellent tooling for exploration and documentation. Operational simplicity Acceptable; works out of the box with CDNs and reverse proxies; few to no client-side libraries required. Excellent; works out of the box with CDNs and reverse proxies, no client-side libraries needed, but many are available and useful. Poor; extra infrastructure is often necessary client side libraries are a practical necessity, specific patterns required to benefit from CDNs and browser caches. Writing data Acceptable; HTTP semantics give some guidance but how specifics left to each implementation, one write per request. Excellent; how writes are handled is clearly defined by the spec, one write per request, but multiple writes is being added to the specification. Poor; how writes are handled is left to each implementation and there are competing best practices, it's possible to execute multiple writes in a single request.

If you're not familiar with JSON:API or GraphQL, I recommend you watch the following two short videos. They will provide valuable context for the remainder of this blog post:

Request efficiency

Most REST APIs tend toward the simplest implementation possible: a resource can only be retrieved from one URI. If you want to retrieve article 42, you have to retrieve it from https://example.com/article/42. If you want to retrieve article 42 and article 72, you have to perform two requests; one to https://example.com/article/42 and one to https://example.com/article/72. If the article's author information is stored in a different content type, you have to do two additional requests, say to https://example.com/author/3 and https://example.com/author/7. Furthermore, you can't send these requests until you've requested, retrieved and parsed the article requests (you wouldn't know the author IDs otherwise).

Consequently, client-side applications built on top of basic REST APIs tend to need many successive requests to fetch their data. Often, these requests can't be sent until earlier requests have been fulfilled, resulting in a sluggish experience for the website visitor.

GraphQL and JSON:API were developed to address the typical inefficiency of REST APIs. Using JSON:API or GraphQL, you can use a single request to retrieve both article 42 and article 72, along with the author information for each. It simplifies the developer experience, but more importantly, it speeds up the application.

Finally, both JSON:API and GraphQL have a solution to limit response sizes. A common complaint against typical REST APIs is that their responses can be incredibly verbose; they often respond with far more data than the client needs. This is both annoying and inefficient.

GraphQL eliminates this by requiring the developer to explicitly add each desired resource field to every query. This makes it difficult to over-fetchdata but easily leads to very large GraphQL queries, making (cacheable) GET requests impossible.

JSON:API solves this with the concept of sparse fieldsets or lists of desired resource fields. These behave in much the same fashion as GraphQL does, however, when they're omitted JSON:API will typically return all fields. An advantage, though, is that when a JSON:API query gets too large, sparse fieldsets can be omitted so that the request remains cacheable.

REST JSON:API GraphQL Multiple data objects in a single response Usually; but every implementation is different (for Drupal: custom "REST Export" view or custom REST plugin needed). Yes Yes Embed related data (e.g. the author of each article) No Yes Yes Only needed fields of a data object No Yes; servers may choose sensible defaults, developers must be diligent to prevent over-fetching. Yes; strict, but eliminates over-fetching, at the extreme, it can lead to poor cacheability. Documentation, API explorability and schema

As a developer working with web services, you want to be able to discover and understand the API quickly and easily: what kinds of resources are available, what fields does each of them have, how are they related, etc. But also, if this field is a date or time, what machine-readable format is the date or time specified in? Good documentation and API exploration can make all the difference.

REST JSON:API GraphQL Auto-generated documentation Depends; if using the OpenAPI standard. Depends; if using the OpenAPI standard (formerly, Swagger). Yes; various tools available. Interactivity Poor; navigable links rarely available. Acceptable; observing available fields and links in its responses enable exploration of the API. Excellent; autocomplete feature, instant results or compilation errors, complete and contextual documentation. Validatable and programmable schema. Depends; if using the OpenAPI standard. Depends; the JSON:API specification defines a generic schema, but a reliable field-level schema is not yet available. Yes; a complete and reliable schema is provided (with very few exceptions).

GraphQL has superior API exploration thanks to GraphiQL (demonstrated in the video above), an in-browser IDE of sorts, which lets developers iteratively construct a query. As the developer types the query out, likely suggestions are offered and can be auto-completed. At any time, the query can be run and GraphiQL will display real results alongside the query. This provides immediate, actionable feedback to the query builder. Did they make a typo? Does the response look like what was desired? Additionally, documentation can be summoned into a flyout, when additional context is needed.

On the other hand, JSON:API is more self-explanatory: APIs can be explored with nothing more than a web browser. From within the browser, you can browse from one resource to another, discover its fields, and more. So, if you just want to debug or try something out, JSON:API is usable with nothing more than cURL or your browser. Or, you can use Postman (demonstrated in the video above) — a standalone environment for developing on top of an anyHTTP-based API. Constructing complex queries requires some knowledge, however, and that is where GraphQL's GraphiQL shines compared to JSON:API.

Operational simplicity

We use the term operational simplicity to encompass how easy it is to install, configure, run, scale and secure each of the solutions.

The table should be self-explanatory, though it's important to make a remark about scalability. To scale a REST-based or JSON:API-based web service so that it can handle a large volume of traffic, you can use the same approach websites (and Drupal) already use, including reverse proxies like Varnish or a CDN. To scale GraphQL, you can't rely on HTTP caching as with REST or JSON:API without persisted queries. Persisted queries are not part of the official GraphQL specification but they are a widely-adopted conventionamongst GraphQL users. They essentially store a query on the server, assign it an ID and permit the client to get the result of the query using a GETrequest with only the ID. Persisted queries add more operational complexity, and it also means the architecture is no longer fully decoupled — if a client wants to retrieve different data, server-side changes are required.

REST JSON:API GraphQL Scalability: additional infrastructure requirements Excellent; same as a regular website (Varnish, CDN, etc). Excellent; same as a regular website (Varnish, CDN, etc). Usually poor; only the simplest queries can use GET requests; to reap the full benefit of GraphQL, servers needs their own tooling. Tooling ecosystem Acceptable; lots of developer tools available, but for the best experience they need to be customized for the implementation. Excellent; lots of developer tools available; tools don't need to be implementation-specific. Excellent; lots of developer tools available; tools don't need to be implementation-specific. Typical points of failure Fewer; server, client. Fewer; server, client. Many; server, client, client-side caching, client and build tooling. Writing data

For most REST APIs and JSON:API, writing data is as easy as fetching it: if you can read information, you also know how to write it. Instead of using the GET HTTP request type you use POST and PATCH requests. JSON:API improves on typical REST APIs by eliminating differences between implementations. There is just one way to do things and that enabled better, generic tooling and less time spent on server-side details.

The nature of GraphQL's write operations (called mutations) means that you must write custom code for each write operation; unlike JSON:API the specification, GraphQL doesn't prescribe a single way of handling write operations to resources, so there are many competing best practices. In essence, the GraphQL specification is optimized for reads, not writes.

On the other hand, the GraphQL specification supports bulk/batch operations automatically for the mutations you've already implemented, whereas the JSON:API specification does not. The ability to perform batch write operations can be important. For example, in our running example, adding a new tag to an article would require two requests; one to create the tag and one to update the article. That said, support for bulk/batch writes in JSON:APIis on the specification's roadmap.

REST JSON:API GraphQL Writing data Acceptable; every implementation is different. No bulk support. Excellent; JSON:API prescribes a complete solution for handling writes. Bulk operations are coming soon. Poor; GraphQL supports bulk/batch operations, but writes can be tricky to design and implement. There are competing conventions. Drupal-specific considerations

Up to this point we have provided an architectural and CMS-agnostic comparison; now we also want to highlight a few Drupal-specific implementation details. For this, we can look at the ease of installation, automatically generated documentation, integration with Drupal's entity and field-level access control systems and decoupled filtering.

Drupal 8's REST module is practically impossible to set up without the contributed REST UI module, and its configuration can be daunting. Drupal's JSON:API module is far superior to Drupal's REST module at this point. It is trivial to set up: install it and you're done; there's nothing to configure. The GraphQL module is also easy to install but does require some configuration.

Client-generated collection queries allow a consumer to filter an application's data down to just what they're interested in. This is a bit like a Drupal View except that the consumer can add, remove and control all the filters. This is almost always a requirement for public web services, but it can also make development more efficient because creating or changing a listing doesn't require server-side configuration changes.

Drupal's REST module does not support client-generated collection queries. It requires a "REST Views display" to be setup by a site administrator and since these need to be manually configured in Drupal; this means a client can't craft its own queries with the filters it needs.

JSON:API and GraphQL, clients are able to perform their own content queries without the need for server-side configuration. This means that they can be truly decoupled: changes to the front end don't always require a back-end configuration change.

These client-generated queries are a bit simpler to use with the JSON:API module than they are with the GraphQL module because of how each module handles Drupal's extensive access control mechanisms. By default JSON:API ensures that these are respected by altering the incoming query. GraphQL instead requires the consumer to have permission to simply bypass access restrictions.

Most projects using GraphQL that cannot grant this permission use persisted queries instead of client-generated queries. This means a return to a more traditional Views-like pattern because the consumer no longer has complete control of the query's filters. To regain some of the efficiencies of client-generated queries, the creation of these persisted queries can be automated using front-end build tooling.

REST JSON:API GraphQL Ease of installation and configuration Poor; requires contributed module REST UI, easy to break clients by changing configuration. Excellent; zero configuration! Poor; more complex to use, may require additional permissions, configuration or custom code. Automatically generated documentation Acceptable; requires contributed module OpenAPI. Acceptable; requires contributed module OpenAPI. Excellent; GraphQL Voyager included. Security: content-level access control (entity and field access) Excellent; content-level access control respected. Excellent; content-level access control respected, even in queries. Acceptable; some use cases require the consumer to have permission to bypass all entity and/or field access. Decoupled filtering (client can craft queries without server-side intervention) No Yes Depends; only in some setups and with additional tooling/infrastructure. What does this mean for Drupal's roadmap?

Drupal grew up as a traditional web content management system but has since evolved for this API-first world and industry analysts are praising us for it.

As Drupal's project lead, I've been talking about adding out-of-the-box support for both JSON:API and GraphQL for a while now. In fact, I've been very bullish about GraphQL since 2015. My optimism was warranted; GraphQL is undergoing a meteoric rise in interest across the web development industry.

Based on this analysis, for Drupal core's needs, we rank JSON:API above GraphQL and GraphQL above REST. As such, I want to change my recommendation for Drupal 8 core. Instead of adding both JSON:API and GraphQL to Drupal 8 core, I believe only JSON:API should be added. That said, Drupal's GraphQL implementation is fantastic, especially when you have the developer capacity to build a bespoke API for your project.

On the four qualities by which we evaluated the REST, JSON:API and GraphQL modules, JSON:API has outperformed its contemporaries. Its web standards-based approach, its ability to handle reads and writes out of the box, its security model and its ease of operation make it the best choice for Drupal core. Additionally, where JSON:API underperformed, I believe that we have a real opportunity to contribute back to the specification. In fact, one of the JSON:API module's maintainers and co-authors of this blog post, Gabe Sullice (Acquia), recently became a JSON:API specification editor himself.

This decision does not mean that you can't or shouldn't use GraphQL with Drupal. While I believe JSON:API covers the majority of use cases, there are valid use cases where GraphQL is a great fit. I'm happy that Drupal is endowed with such a vibrant contributed module ecosystem that provides so many options to Drupal's users.

I'm excited to see where both the JSON:API specification and Drupal's implementation of it goes in the coming months and years. As a first next step, we're preparing the JSON:API to be added to Drupal 8.7.

Special thanks to Wim Leers (Acquia) and Gabe Sullice (Acquia) for co-authoring this blog post and to Preston So (Acquia) and Alex Bronstein(Acquia) for their feedback during the writing process.

 February 11, 2019

 11 min read time

 Permalink

Categories: Drupal

New website built in WP - Advanced skillset required - Philippines Only - Upwork

WordPress Work From UpWork - Wed, 02/13/2019 - 18:54
I need to build a new website from scratch.  This will involve taking an existing competitive website and rewriting the content as well as the build out of the website for mine.


Posted On: February 14, 2019 11:41 UTC
Category: Web, Mobile & Software Dev > Web Development
Skills: PHP, Web Design, WordPress
Country: United States
click to apply

New website built in WP - Advanced skillset required - Upwork

WordPress Work From UpWork - Wed, 02/13/2019 - 18:54
I need to build a new website from scratch.  This will involve taking an existing competitive website and rewriting the content as well as the build out of the website for mine.


Posted On: February 14, 2019 02:11 UTC
Category: Web, Mobile & Software Dev > Web Development
Skills: PHP, Web Design, WordPress
Country: United States
click to apply

Lullabot: Introducing the Quicklink module for Drupal

News from Planet Drupal - Wed, 02/13/2019 - 18:03

The mobile web is too slow. According to the HTTP Archive, the median time to first contentful paint is 5.8 seconds — this means that the average person waits almost 6 seconds just to view an average website on their phone. 

Categories: Drupal

Virtual assistant to help with e-commerce product listings - Upwork

WordPress Work From UpWork - Wed, 02/13/2019 - 17:47
We have several new ecommerce stores for a range of imported products and we need help with pulling together lots of product information and posting on our sites.

You must:

- be a great communicator
- be proficient on Google Sheets,
- be savvy enough to navigate Shopify, wordpress and Woocommerce (and bonus points for experience on these)
- be available immediately

What this will entail:

- cross-referencing several data sources and updating online portals
- accuracy and attention to detail
- renaming and uploading images
- using google translate to read descriptions to use as source materials

Please only apply if you want to take your time to do the job well. We'll run you through everything so you know what to do.

If everything goes well we will need on-going admin support.

This is a chance to work on a complete project and be part of the team in launching a range across several web properties.


Posted On: February 14, 2019 02:11 UTC
Category: Admin Support > Personal / Virtual Assistant
Skills: Content Writing, Data Entry, Internet Research, Shopify, Virtual Assistant, Woocommerce, WordPress
Country: United Kingdom
click to apply

Blair Wadman: Easy way to find the Drush command you are looking for

News from Planet Drupal - Wed, 02/13/2019 - 17:22

Both Drush and Console have built-in help. If you type drush, you will get a long list of available commands. If you type drupal, again you will get a long list of available console commands. If you can’t remember the exact command to use to do what you need, you can scroll through the long list of commands to find the one you want.

Categories: Drupal

Drupal Association blog: Keeping up to date with information for Drupal Event Organizers

News from Planet Drupal - Wed, 02/13/2019 - 17:10

The events that every year bring us together all over the World are the lifeblood of our vibrant and diverse community. From BADCamp in California, USA, through Global Training Days in Omsk, Russia to Contribution Weekends in Leeds, UK, we have a combined wealth of knowledge and experiences but also challenges and opportunities.

At the Drupal Association, we value highly the commitment made by those who volunteer their time to make these events happen. If I wasn’t British, and therefore terribly understated, at this point I would probably say “You rock!”.

As an event organiser, I wanted to take the opportunity to bring to your attention a few things happening in the community that we hope will help you in your efforts.

The Event Organizers’ Group

We were very pleased to see the creation of a growing group of event organizers forming and beginning to have regular meetings to share experiences and resources. One of its founders, Kaleem Clarkson, has blogged about this and their plans for the future.

To help with their formation, we helped them become one of the first groups to create one of the new Community Group Sections at Drupal.org/community/event-organizers.

One thing that is super important, though, is that this group has representation by event organizers from all around the World. Wherever you live, do join this group, make your voice heard and ensure that it meets in a way that works for you.

The Event Organizers’ Round Table with Dries Buytaert

One of the requests we had from the group was to be able to spend more time discussing their aims with the Project founder, Dries Buytaert.

Dries agreed that spending quality time with representatives of such a key part of our community was highly valuable, so we have created a round table at DrupalCon Seattle 2019 to which event organizers will be invited to attend and participate.

The invites will be sent to the mailing segment introduced below - make sure you read on!


Image of Dries taking notes from a previous Round Table, courtesy Baddý Sonja Breidert

A mailing list segment especially for event organizers

To ensure that we can alert event organizers to activities like the above, we have created a special segment in our mailing list system that allows us to send updates to only those that want to hear about them.

If you are an Event Organizer, or looking to become one in the future, I highly recommend you visit your user profile on Drupal.org and check the box “Contact me regarding local organizing (camps, groups, etc.)”

For the above mentioned Round Table with Dries Buytaert, we will be sending invites to member of this mailing list so make sure you are on it!

Categories: Drupal

New website to be created for Odysseus Offshore Income Fund - Upwork

WordPress Work From UpWork - Wed, 02/13/2019 - 16:43
Odysseus Offshore Income Fund:
1-3 pages, intro explanation, about us, etc.

domain name - odysseusfunds.com

Please do in wordpress and make easy to edit and ad pages and content for us.


Posted On: February 14, 2019 02:11 UTC
Category: Web, Mobile & Software Dev > Web & Mobile Design
Skills: Content Writing, Graphic Design, HTML, HTML5, Web Design, Website Development, WordPress
Country: Canada
click to apply

Google Webmaster tools Blog articles - how to - Upwork

WordPress Work From UpWork - Wed, 02/13/2019 - 16:43
We would like to hire someoen to write a few blogs for us about very specific things that we run in to a lot.

-How to do change of address in webmaster tools (like if you domain changes from foo.com to widget.com
-The different between Admin and Owner and how to set them up

would like high quality steps and screenshots walking the reader through each aspect. here is a good example of what sort of article we are needing

https://chartio.com/learn/marketing-analytics/how-to-add-google-analytics-tracking-to-a-website/

https://www.monsterinsights.com/how-to-add-google-analytics-to-wordpress-without-a-plugin/


Posted On: February 14, 2019 02:11 UTC
Category: Sales & Marketing > SEM - Search Engine Marketing
Skills: Content Writing, Google Analytics, Search Engine Optimization (SEO)
Country: United States
click to apply

Acquia Developer Center Blog: Building Usable Conversations: Conversational Usability Testing

News from Planet Drupal - Wed, 02/13/2019 - 15:31

In this fifth installment of our series on conversational usability, our focus shifts to conversational usability and the process of evaluating and improving conversational interfaces that often differ significantly from the visual and physical interfaces we normally use to test with end users.

Tags: acquia drupal planet
Categories: Drupal

InternetDevels: Updated and stable Webform module in Drupal 8 for form creation

News from Planet Drupal - Wed, 02/13/2019 - 13:38

Various forms are the heart of website’s interaction with the user. They are vital for usability, conversions, marketing analytics, and more. So form building tools are in demand — the Drupal Webform module ranks 7th on the 42,000+ list of contributed modules. The Webform module has recently got its stable version for Drupal 8. We will give it an overview and show an example of creating a simple form with the Webform module.

Read more
Categories: Drupal

Build a Landing Page using Divi+WordPress from an InDesign file - Upwork

WordPress Work From UpWork - Wed, 02/13/2019 - 11:13
Help needed to develop a simple landing page for desktop and mobile using:
-WordPress
-Divi plugin, by Elegant Themes
-An InDesign file that contains all of the design

Please see the images attached for reference

Comments:
-We will provide domain + blank WP site
-We provide the hosting
-We provide 100% design + content
-Need to integrate a standard contact form
-Need to apply Google Tag Manager code


Posted On: February 13, 2019 14:43 UTC
Category: Web, Mobile & Software Dev > Web Development
Skills: Adobe InDesign, Website Development, WordPress
Country: Israel
click to apply

Flocon de toile | Freelance Drupal: Provide a footer to a micro site with Drupal 8

News from Planet Drupal - Wed, 02/13/2019 - 11:04

The Micro Site module allows you to set up a Drupal web factory, from a single Drupal 8 instance, to power a multitude of sites, of a different nature if necessary. Micro Site provides a new content entity that allows you to customize these different site types at will, using the APIs available on Drupal 8, and modify their behavior according to business needs.

Categories: Drupal

Seo& Graphic optimization - Upwork

WordPress Work From UpWork - Wed, 02/13/2019 - 10:46
Hello.. I have to improve the SEO of my website www.lemarcheholiday.net and generate more leads and more potential customer use our website to plannig the next vacation to my region

I need to :
- improve and optimize the seo Title, Text, make more easy and friendly and catch more audience and request
- maybe make more interesting the home page etc..

I must improve the website and make more interesting in term to have more leads. I want working with people motivated and have experience about SEO travel industry, writing etc


Posted On: February 13, 2019 14:43 UTC
Category: Web, Mobile & Software Dev > Web Development
Skills: Content Writing, Google Analytics, Internet Marketing, Italian, On-Page Optimization, Search Engine Optimization (SEO), SEO Backlinking, SEO Keyword Research, SEO Writing, Travel Writing, Web Design, Website Development, WordPress
Country: Italy
click to apply

Great Website Designer for simple Quick Turnaround project - Upwork

WordPress Work From UpWork - Wed, 02/13/2019 - 10:25
Website and branding available. Content ready to go. Need to go live.

Professional web designer.

Need to be visually creative and fast.


Posted On: February 13, 2019 14:43 UTC
Category: Web, Mobile & Software Dev > Web Development
Skills: Graphic Design, Web Design, Website Development, WordPress
Country: Switzerland
click to apply

Translation services. Landing page from English language to Hebrew - Upwork

WordPress Work From UpWork - Wed, 02/13/2019 - 09:31
Translation services. Landing page from English language to Hebrew. Page is streetarttourmadrid.cooltourspain.com The project is focused on several keywords that will need to be the most important thing in the project. Please see attached. It's around 900 words.


Posted On: February 13, 2019 14:43 UTC
Category: Translation > General Translation
Skills: Content Writing, English, Hebrew, Proofreading, Translation, Translation Hebrew English, WordPress, Writing
Country: Spain
click to apply

Agiledrop.com Blog: Interview with Taco Potze: Why Drupal was the CMS of choice and what potential open source has

News from Planet Drupal - Wed, 02/13/2019 - 07:54

We had a delightful talk with Taco Potze, co-founder of GoalGorilla, Open Social and THX. Taco revealed to us why his team decided for Drupal among the various possible CMS choices and what Drupal initiative they are most excited about. He thinks open source has the potential to balance out the power of tech giants and give people all over the world equal opportunities. Take a look to find out more about his projects and his contributions to the community.

READ MORE
Categories: Drupal

wordpress developer needed to create basic navigation interface for F&B site - Upwork

WordPress Work From UpWork - Wed, 02/13/2019 - 05:06
looking for someone to build an interface within a page like this :

https://www.quicksand.la/location/quicksand-culver-city/#soups-sides-copy

where the menu items change when you click on the categories.

  there are 3 locations each one with different page and with different menus. content needs to be user  editable.

please submit  proposal with  time quote.

always have work.  so if this is done well, on time, within a reasonable budget,  there will be more work.


Posted On: February 13, 2019 14:43 UTC
Category: Web, Mobile & Software Dev > Web Development
Skills: CSS, PHP, Web Design, WordPress
Country: Singapore
click to apply

[REQUEST] Plugin that scraps Poshmark & Mercari reviews?

Talk about plugins - Wed, 02/13/2019 - 02:53

I know there's a plugin for Amazon reviews but I am hoping to find a plugin that grabs reviews from Poshmark and Mercari, where I have a reasonable amount of reviews on.

Thanks!

submitted by /u/smdx459
[link] [comments]

Navigation

Let's Talk


Let's talk about your website:
Get Started

My LinkedIn profile



LocalSolo Freelance