Theoretically, this should be possible with a bit of work right now. Let's say you have site A that has the collection on it and site B that wants to also use the collection. You can expose an API on site A using HTTP functions that gives access to the collection. Then, on site B, you can use the fetch API to call site A's API. If you try such an approach, be very careful security-wise. Make sure your HTTP functions are checking that the calls are coming from site B and not some other source.

The wix-paid-plans API is probably the right place to get started. Check out the getCurrentMemberOrders() function which you can use to get the plans the current member has paid for. You can use that information to decide what you're going to present to the member.

Depending on your situation, you can try using the emailContact or emailUser funtions in conjunction with Triggered Emails.

@simon.adams Yes, right now all message publishing must be routed through the backend. There are plans for a client-side publish function as well.

Alright, here it is. As I said we're not completely done with this so it is subject to change. A little explanation: It is a news site where we've implemented a breaking news feature using the Realtime API. Members of the news site can subscribe to categories of breaking news they'd like to be alerted to. The categories and member subscriptions are stored in two database collections. There are three areas with code. First is the home page, which is where alerts are received. Second is a lightbox opened from the settings icon on the home page, where members can manage their subscriptions. Third is an admin page, where the admin sends messages to subscribers of various categories. To see all this in action, you'll need to have the site open twice - one acting as a member and one acting as the admin. There's a bit I left out here, but I leave that up to you to discover. Here is the template so you can try it out yourself. Let me know how it goes.

So the first one is the real estate example from above that has recently been added to the examples site: https://www.wix.com/corvid/example/real-time-notifications-for-new-real-estate. And the second one, we're going to take a different direction because it is a bit complex. It will probably not be on the Corvid site with the other examples. Instead, we will be writing a tutorial based on the example and you will be able to get that example from the tutorial. This make take a bit of time. Could be that I can get you a link to the example before the tutorial is written if that will help.

We have two full use-case examples that are in the works.

Again, I'm no expert here. You can try adding which is an HTML line break.

Hey all, Please note that we've updated the syntax for the jobs JSON to split the "functionLocation" into "functionLocation" and "functionName". See the updated syntax at the beginning of this thread. Currently, the old configuration will work as well until the end of December, but you are encouraged to update to the new syntax.

Hey Giri, As far as the bulk operations go, they are limited to 1000 items and 0.5MB in payload.

Might I suggest this example as well: https://www.wix.com/corvid/forum/corvid-tips-and-updates/example-todomvc

Link is not working.

Instead of using XMLHttpRequest(), try using the Wix Fetch API documented here.

Looks like you're trying to send the email after you send the browser to the dashboard page. Try moving the to() function to after sending the email. If you want to send an email to yourself as well, you'll need to send it using the backend version of emailUser(). From frontend code, you can only email the currently logged in user (who in this case is not you).

This is somewhat doable by changing the text color of the text in a row using richtext columns as mentioned above. However, I think you should consider using a repeater instead of a table. That will give you a lot more flexibility. You can definitely conditionally change the background color in a repeater "row" (their called "items" in a repeater) based on its data. (Look at onItemReady to do so.)

You should leave it that way...but it looks like there's an extra .to in the code. So just: wixLocation.to(wixLocation.url);

@givemeawhisky Yes, this is an autocomplete bug on our side. The code will work fine even though the code panel thinks there is an error. I will pass on this bug.

I think I've been able to reproduce the issue you guys are having. Looks to be a bug on our side that is actually not related to the mobile menu. Good news is that I have a couple of workarounds. 1. Seems to work if you add the button directly to the header. Don't place it in the body of the page and then move it to the header. 2. Use a dynamic event handler instead of the properties panel, which creates a static event handler. So, something like this: $w.onReady(function () { $w('#myOpenButton').onClick( () => { $w('#menuContainer1').open(); } ); }); Let me know if this helps.

@Quinten Althues (QkeleQ) Unfortunately the more advanced example has been delayed.

Here, I'm assuming you populate your table using a dataset connection. You can change the format of the date fields in your table using code similar to this: export function myDataset_ready() { // get the table's columns let columns = $w('#table1').columns; // change all date columns to type string columns = columns.map( (column) => { if(column.type === 'date'){ column.type = 'string'; } return column; } ); // reset the table's columns $w('#table1').columns = columns; // get the table's rows let rows = $w('#table1').rows; // rows = rows.map( (row) => { row.dateField1 = // changed value row.dateField2 = // changed value return row; } ); $w('#table1').rows = rows; }