You are not logged in.
Pages: 1
I created a custom action for my view but when I click on it, none of the code in the corresponding file is run. I know the file is in the right place and there aren't any errors because if I just copy/paste the link location from the icon in the view in my browser and go to it directly, everything in the code is run when I check it. I checked the console and no errors or any other messages are generated when I click the icon in the view. I can't understand why it works when browsed to directly but not when I click the link, any thoughts?
Thanks
Offline
That's incredibly weird -- I've never seen that behavior before! When you click the icon it sends you to the exact same URL as when you copy and paste it?
Offline
Oh, I just thought of something else -- if you're using certain icon classes in a view, Javascript will auto-catch the click and perform a different operation (e.g. Archive, Feature, and Approve will be auto-caught). That may be what you're running into if you're using any of those! Unfortunately I don't presently have a solution on hand for that, but I plan on fixing it soon so that those icons can be used properly for custom actions.
Offline
The two classes that I'm using are icon_dialog_add and icon_disabled. When I click on the disabled icon in my view, nothing happens. The code in the associated file is not run and the Bigtree.growl that I have set isn't displayed (I do have header("Content-type: text/javascript"); at the top of my php file). When I click on the dialog_add icon, rather than running the code thorugh ajax it actually takes me to the link in the browser and outputs all the HTML/JS like it was a source code view (I'm assuming this is because this file also has a header("Content-type: text/javascript"); at the top and the browser treats the page like it was a .js file). Now on this one, the php code is actually being run it's just not staying on the view page like I need it to. But since it is running the code and loading it in the browser, I know that I have the action route for the file setup correctly.
I know that I'm not using any of the three classes you mentioned, but I'll try changing that to different ones to see if that has any effect. If not, I can start trying to debug things and see if I can pinpoint where the issue is. Just wanted to start here first and see if you had experienced something like this before.
Thanks
Offline
One quick thing I forgot to mention. On the denied icon, if I copy the link location off of it and paste it in the browser then I get the same effect as when I click the add_dialog icon. The HTML/JS code is displayed in the browser and the php code is run. So I know my action routes for both files are being run correctly. The problem has to be something on the view page itself that is treating them different than "normal" view actions.
Offline
Ok looking at: core/admin/auto-modules/views/_common-js.php There is a click event associated with .icon_disabled that is just set to return false. Was that created because of the context that icon has with pending changes? Does that mean that that icon is in essence "off limits" to custom actions? I changed it to a different icon and now I'm getting the same behavior that I have with the icon_dialog_add. And as I look at this file, I'm only seeing click events associated with delete, approve, featured, and archived. Does that mean that only those four icons are capable of performing ajax calls and that the rest will always be treated as links? I'm guessing there's not a way to override that behavior?
Offline
icon_disabled is another one I forgot to mention - that simple stops all clicks from going through (so that's definitely an issue!). The other issue that you'll run into after I fix this one is that custom actions don't respond the way you're trying to get them to - they normally redirect the user (rather than doing it via AJAX like the built-in actions do). You'd need to perform your PHP, call $admin->growl, then redirect back to the view.
Offline
Looks like you got all the info I just replied with before I was able to send it I'm going to fix the icon issues in 4.2.13 -- I'll post the commit link here if you want to fix it in the meantime once it's ready!
Offline
Ok that sounds great! So then how would I redirect the user back to the view? I noticed that in the pre-defined ones (approved, archived, etc.) that the view id and the id of the item are passed to the ajax page using url variables but with custom ones it seems like I only have access to the id of the item through $bigtree["commands"]. Would it be possible to just have the id of the view added on as a url variable to custom actions as well? So the id of the item would still be contained in $bigtree["commands"] but then the id of the view would also be passed so it could be recached and used to have the user redirected back.
Offline
The easiest way to redirect back would be:
BigTree::redirect($_SERVER["HTTP_REFERER"]);
Offline
I had to release a 4.2.13 upgrade to fix a critical UTF-8 character bug in 4.2.12, so I got this fix in there as well. In 4.2.13 you should be able to use all those CSS icons without getting the Javascript behavior associated with the core actions.
Offline
Awesome! Thank you!
Offline
Pages: 1