I've started using wit.ai and they say to come here to ask any questions about issues.
I've ended up with 4 duplicate responses after trying different things. These responses are now conflicting with each other and I can't delete them. Editing them doesn't stop the reported conflict nor does the option to delete them appear.
Wait for some time(because wit takes long time to update the stories) and go to 'Actions' tab. You will find the list of all actions and responses. In this list, there will be a 'Remove' button for unused actions and responses.
It's annoying - I don't know why these changes don't take effect instantly. Usually a few refreshes and a little waiting does the trick for the conflicts, then the deleted actions will appear in your Actions tab like so ready to be removed:
Related
My developer has integrated facebook pixel on my shopify site. But after 3 days it is showing me this error in diagnostic window. I am trying to resolve this at my end.
You’re sending the same event ID for many instances of your ViewContent events. Event IDs are unique identifiers that are used to deduplicate identical events received from your pixel and the Conversions API so they’re not counted twice. To ensure that Facebook is accurately counting your events, each unique event instance needs its own unique event ID.
This may cause issues with the measurement of your events and the attribution of your ad campaigns.
So to remove this I simple enabled "external_id" parametre from "Automatic Advanced matching" option but I am not quite sure that I did right thing or not as I am new in integrating this. After solving this, I am seeing this error now as mentioned in screenshot
Is there something in code, that I need to change to resolve this issue.
Note: Setup is made through a partner integration.
Please help me to resolve these errors. If you need more info, please let me know.
Any help will be appreciated!
Thanks!
I tried both the option
Switching OFF "Automatic advanced matching"
Switching ON "Automatic advanced matching" -> Show options (External ID --> ON)
Finally I observed we have to go with option 1. Still the issue will come single time for each conversion event. After first time we encounter the error we have to move it to ignore list. For each event we will get error we have to do similar trick. Once all event encountered such error and all ignored problem might be solved.
So far I have done for 4 events which I got error. After that I have not got the error for those 4 events. Waiting for my other 2 events error.
But not sure the problem is solved permanently but not seeing any problem for those 4 events for 48 hours. But definitely shopify and facebook together need to solve. But both passing ball to one another.
Using bookmarks to jump from any point in the story is a very useful feature. But can we use Jump and bookmark to jump from one story to another? It seems to be possible as the bookmarks drop-down shows all the bookmarks across the stories not just the bookmarks within the story. But my doubt is how will it recognize the intent of the new story to be executed.
Any example of wit application would be helpful.
Thanks in advance.
I answered with a homemade solution here wit.ai - unrecognised user entries
Essentially, you can create an action call "jumpTo[Insert-Your-Story-Name]Story". On your side, this action "emulates" the fact that the users sent a pre-determined message that will triggered your another story.
It works, but I don't know if it's the best way to do it.
If I make an edit to a Trac ticket, but someone beat me to it, this message is displayed:
Ideally, I would read this message and figure out what I can overwrite and what I should not. But, depending on this message to keep users from overwriting what was submitted is not something that we should depend on:
This may sound a little harsh, but you'll see, when you do usability tests, that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it.
Is there a better way to prevent these overwrites in Trac - e.g., if a ticket has been modified while you were modifying it, you must refresh the page, etc?
Yes, if the server would send the page modified outside and if the javascript running in your browser could merge that into your local changes. But noone has implemented it in the current trac.
Let's say I have a plugin Foo in osclass. In that plugin we register a hook for when an item is posted. According to the osclass hooks documentation the only hook that is run when an item is posted is posted_item.
But as far as I can tell from looking at the code this is run after the initial item data has already been validated and stored in the database. What if a validation of some plugin specific code fails and I would like to show the user an error message and present him with the form again to give him/her the chance to alter this information? Much like if you try to submit a new item but don't fill in one of the base information like description for instance.
I can't seem to find a way to do this. Only workaround I find to avoid the item being posted despite containing invalid plugin specific data, without editing the main osclass code, is to delete the posted item again in the posted_item hook callback function of my plugin. This feels extremely cumbersome and also requires every other plugin to check that the item still exists to make sure they don't save data connected to an item that is now deleted.
What I would like, and wonder if I have missed, is a hook that is run when an item is posted but before it's written to the database and have the ability to generate "errors" that would cause the item to not be posted and the user redirected back to the form with the "error" displayed just like for the basic item information.
Anyone have a solution I have missed? This feels like a very important part of plugins and without it posted items could become very fragmented.
A user on the osclass forums (teseo) told me about the undocumented hook pre_item_add that can be used.
<?php
function cust_my_plugin($aItem) {
osc_add_flash_error_message('My plugin has a complaint.');
$pItem = new CWebItem();
$pItem->redirectTo( osc_item_post_url() );
}
osc_add_hook('pre_item_add', 'cust_my_plugin');
?>
He also sais
The only bad news is that you can't merge your plugin validation
process with that of the core script, so if the ad had an error
related to your plugin and other errors, it would be rejected twice,
one by your plugin, the second by the core script. I couldn't see any
workaround for this little issue.
I'm working on a Rails application. Two of my models are notes and attachments. The user can create notes and add attachments to them. This is standard stuff and I already have this working fine.
Currently, the user must create a note before they can add attachments to it. I'm looking to implement a more streamlined workflow for the user, similar to the familiar email workflow where you can add attachments to an unsaved email. However, the key is that I don't want the user to even have to save a draft of the note before the attachment can be added, and I want this unsaved note to be abandoned if the user navigates away (I don't want to have the additional complexity of unsaved/unpublished notes).
I know that when the note hasn't initially been saved yet, I can create the attachments without the link to the note, and then establish the link when the note gets saved. The part I'm drawing a blank on is how do I remove the unused attachments if the user breaks off the note creation process? Is there a hook that I'm missing that allows me to see that the user broke off?
Without such a hook, the first solution that comes to mind is a nightly cleanup script that runs via cron that would find all of the unattached attachments and remove them (perhaps filtering by attachments that have been created more than 24 hours ago). Is this the best solution?
There really isn't any kind of trigger to let you know when to clean those up, since a user can just leave the site without "logging out" or some other action. So that leaves you with a background job not attached to user action. In your case I think a nightly cron is nice and simple and would fit this situation well.