Imagefield is not working properly and I get this lengthy error -
{ "status": true, "data": "\x3cdiv id=\"edit-field-image-0-ahah-wrapper\"\x3e\x3cdiv class=\"form-item\" id=\"edit-field-image-0-upload-wrapper\"\x3e\n \x3cdiv class=\"filefield-element clear-block\"\x3e\x3cdiv class=\"widget-preview\"\x3e\x3cdiv class=\"imagefield-preview\"\x3e\x3cimg .............
whenever I upload image. After a bit of detective work, I found out that my own module, which is written for creating custom content type, is causing imagefield to fail. Does anyone know what usually trigger this type of error? Your help is much appreciated.
Imagefield - 6.x-3.7
CCK - 6.x-2.8
Filefield - 6.x-3.7
drupal 6.x
Its tough to say unfortunately. I suspect its something to do with AJAX. Try debugging the Javascript using Firebug in Firefox.
I'm not sure how related this is to your json output but if you have a custom ahah callback sometimes there are conflicts between imagefield or any drupal form file. So it was recommended here:
http://drupal.org/node/399676#comment-1438662
To use drupal_to_js instead of drupal_json when printing the callback status and data.
// don't call drupal_json()
// print drupal_json(array('status' => TRUE, 'data' => $output));
// send the updated file attachments form... .
// ahah.js uses an iframe and the header output by drupal_json() causes
// problems in some browsers.
print drupal_to_js ( array ( 'status' => TRUE, 'data' => $output ) );
exit;
After days of frustration with form fields not keeping thier values until after the imagefield had been uploaded i also found that the ahah.js iframe behaviour of filefield and imagefield can conflict with other ahah functions sitting on other form fields.
Patching ahah.js by following patch #19 here fixed this for me.
http://drupal.org/node/806500#comment-4004316
I had similar problems few days ago. I've used Ubercart module, particularly its product module. There is an imagefield in the product creation form. So I got the same message (JSON output) trying to add picture to product. Important note: such a behavior was observed only in Chrome (I'm on dev-channel of it). Firefox handled form successfully.
I didn't investigate the reasons of such a behavior unfotunately. But I advise you to check your site in different browser(s) too.
Related
I thought I’d be able to update the featured image using this code…
wp.data.dispatch( 'core/editor' ).editPost( { featured_media: 10 } );
However, I get an error:
Uncaught (in promise) Error: The entity being edited (postType, undefined) does not have a loaded config.
What needs to be changed?
Have you tried this:
wp.data.select( 'core/editor' ).getEditedPostAttribute( 'featured_media' );
wp.data.dispatch( 'core/editor' ).editPost({ featured_media: 10 });
I had the same error show up in my browser console, when I was trying to make a custom post type editable through a custom-made block. In my case, it wasn't a problem with the gutenberg block itself (i.e. the js file or the registration of the block), since I could use the block in other post types without the error showing up in the console.
I would suggest checking the slugs/names of any taxonomies (and perhaps post meta fields) which are registered for your specific post type. I think I must have confused the Wordpress REST API as it was loading the post in the gutenberg editor because I had registered a reserved word as one of my taxonomies (I had a taxonomy with machine name "type"). I changed the taxonomy to "taxon_type" (hoping to avoid any name clashes), and the error went away!
I initially thought that it was a problem with a Wordpress API call that I was making in the block itself, but I believe the error message is signaling that the gutenberg editor is having trouble loading your post type for whatever reason.
I am writing a WordPress plugin that has an AJAX element to it - blocks of HTML are fetched by the front end from the plugin using AJAX.
I am having difficulty joining up the pieces here, and I suspect it is just a terminology issue. How would I implement a page completely provided by the plugin?
The content of the page will be HTML - the plugin can generate this in response to POST or GET parameters.
There needs to be a route to this page. The route does not have to be user-friendly or a REST style - just some kind of URI that gets to the plugin. Is there perhaps a way to register a custom page with an arbitrary name, without having to create it as a WP post?
I would like all this to be self-contained in the plugin, so should not involve the administrator having to create posts or pages, or have to add anything to the theme.
Ideally I would avoid any URLs that go into the wp-admin directory. End users don't belong in here.
I would strongly suggest referring to https://codex.wordpress.org/AJAX_in_Plugins#Ajax_on_the_Viewer-Facing_Side
You need to have a php script in your plugin directory that returns what you request, and you need to determine that url at run time for reference in your ajax. The above link gives an example for enqueuing and using wp_localize_script() to provide the url for your custom php script.
wp_enqueue_script( 'ajax-script',
plugins_url( '/js/my_query.js', __FILE__ ), array('jquery') );
// in JavaScript, object properties are accessed as
// ajax_object.ajax_url, ajax_object.we_value
wp_localize_script( 'ajax-script', 'ajax_object',
array( 'ajax_url' => plugins_url( '/php/myapi.php' ));
Your javascript file will be included on every page and will listen for events on the page which require a block of HTML, as you've described it.
Your file myapi.php then needs to take a request, probably using a query string, get the appropriate content from the wordpress api, and respond with said content, which your javascript will put into place.
To have access to the wordpress api as well though, you have two options:
Force wordpress to run starting with your file, by including wp-load.php. This is probably not the cleanest way.
Set up a custom page or slug to direct to your plugin.
I would advise the second option, and advise a slug, in which case you may find this post helpful: wp_rewrite in a WordPress Plugin
From Jason's comment, based on the link above:
The rewrite rules are mentioned a lot, but are really a distraction -
they just help to make URLs look more "friendly", which was not an
objective here. The key is: register a custom GET parameter; look for
that parameter early in the page rendering process; if you find the
parameter is set, then output/echo stuff and die(). There are a
number of hooks that can be used to look at the parameters, chosen
dependin on how much you want WP to set up and process first.
I would like to create a custom views, because some database fields are not accessible by drupal views UI. I just exported an existing view into a file called my_module_views_default.inc that contains the hook_views_default_views() function. and by the drupal views2 document state that the hook gets called automatically, but it doesn't.
Also i want to know the path, we are giving the path in the code here
$handler->override_option('path', 'my_earnings');
That means we can see the views in the link http://localhost/drupal6/my_earnings ??
and
in my .module file, i use the hook_views_api as follows
function mymodule_views_api() {
return array(
'api' => 2,
'path' => drupal_get_path('module', 'my_earnings'),
);
}
I have found the document Using default views in your module and i created a new module, and i exporting a existing view. Then i placing my exported views into new module in file mymodule.views_default.inc. My views should now be listed as Overridden on the view list page and clear the Views cache. Revert these views, they will be removed from the database, but will remain in code.
Thanks alot to all..
I was caught with the same issue where i needed to join the two table in view. fortunately i found these links
http://drupalmodules.com/module/reverse-node-reference module enhances views with reverse relationships for node reference fields.
you may also need http://drupal.org/project/noderelationships
Using these module i don't think we need any custom module writing for view.
Hello im a newbie at using Drupal, and have come across a block in my progress. I have been using CCK to add new content types to my forms. I was wondering if there was any way to add to the form that is generated so that i may contain the elements and also insert visual html code like head rules etc. I have dabbled with the hook_form_alter() and it does not seem to help me in my efforts. Ive been through adjusting tpl.php files and such and have made no progress. Please if there is any one there in the inter-webs who is knowledgeable on this matter your advice would be greatly appreciated.
Here is just an example of what I would want to do within the form:
1. Contain field elements within DIV's
2. Add HTML Content into the form
If you want to customize the markup for a for you can create a theme function for it and make the form use it with hook_form_alter. This has nothing to do with CCK which is used to customize a content type so you can add additional content to a content type.
hook_form_alter does not help you in altering an edit form containing cck fields because cck fields are added after hook_form_alter call.
You need to theme your form like this:
Create a module and put this hook implementation in it:
function mymodule_theme($existing, $type, $theme, $path) {
'your_form_id' => array(
'arguments' => array('form' => NULL),
'template' => 'my_template',
)
}
Then create a file named my_template.tpl.php in your module directory.
Now empty your cache.
In that file, you can render form elements separately, like this:
<?php
print drupal_render($form['a_form_element']);
print '<h2>blah blah blah...</h2>';
print drupal_render($form['another_form_element']);
// this one is for rendering all the remaining items, like hiddens:
print drupal_render($form);
Use devel module during development. It contains many useful tools that makes development much easier.
Raw HTML CCK Field (Drupal 6) - no filters, formats or editor
Simple Fix! Just use plain text format for unfiltered HTML. Then convert it back to html in a field .tpl when the node is built.
Plain Text format on a CCK field will convert the HTML tags to entity special characters (this would make is so it reads like code on the page instead of being actual html tags). It stores the string encoded using php's htmlspecialchars($text, ENT_QUOTES, 'UTF-8') inside of drupal's check_plain() function.
The cleanest simplest way to decode it, is in a field tpl file. This avoids hooks, hook order problems, looping bugs, and performance issues. This is done by adding tpl files to the base themes: hq_base, odyssey_base and odyssey_admin. Here is how drupal decodes plain text on a cck node edit form: print html_entity_decode(strip_tags($text), ENT_QUOTES); Note - html_entity_decode turns php tags into html comments when it decodes back to html. Here are sample files with the correct naming convention to give php control over the fields:
• content-field.tpl.php
• content-field-[your_field_name].tpl.php
content-field.tpl.php is a copy from the cck contrib into the theme folders, this is a contrib override to make it available in the theme, and should not be modified (unless you wanted to change all the fields in the theme). The field specific file is also a copy of the tpl, it will work once the override file is there. Then decode to html in the field tpl file:
• // print $item['view'];
• print html_entity_decode(strip_tags($item['view']), ENT_QUOTES);
Drupal Version Note:
The tpl files are slightly different in Drupal 7 and Drupal 8. But the html_entity_decode() is a php function that won't change per Drupal version.
Security Note:
This decode trick for getting raw HTML goes against the way Drupal was built for text formatting security. It means that anyone with permissions to edit the page now has permissions to edit html structure, and add script tags on the page. This can break layouts, and potentially be dangerous. You are relying on editing permissions for security here, instead of Drupal's normal Formats-per-Role security.
I have a node with many CCK fields. I want to hide a field from anonymous user. I found there are roughly two approaches from http://www.lullabot.com/articles/modifying-forms-5-and-6. First, I tried theme_theme() with the code below
function ssaa_theme1(&$existing, $type, $theme, $path) {
return array(
'volunteer_node_form' => array(
'arguments' => array('form' => null),
),
);
}
function ssaa_volunteer_node_form($form) {
$out = '';
if (user_is_anonymous()) {
unset($form['field_active']);
}
$out .= drupal_render($form);
return $out;
}
This simple code worked well as I expected but produced strange result too. Save/Preview buttons are appeared on the top of the form and I couldn't move them to the bottom. At first I suspected drupal_render() function but it didn't do anything about the order. It produced same result when ssaa_volunteer_node_form() function was empty.
So I tried second option which uses hook_form_alter() and succeeded. But I still want to figure out why first approach didn't work properly. I think it's more easy and light way to do what I want to do.
Any ideas?
If you only want to deny this one field to users, it makes sense to form_alter it. Otherwise, I also suggest you use Content Permissions. It will give you the power to toggle such settings for all your fields without needing a text editor.
CCK Field input forms do not accept hook_form_alter() very well. They are inserted into the node edit form late in the cycle, so to speak.
This example demonstrates how disable CCK form elements, it can be adapted to suit your needs.
As you have a very specific need, you might want to look at the new Field Permissions module. It is still in development (and I have not tried it), but it allows you to opt-in individual fields to Content Permissions. This prevents your Permissions screen from getting cluttered and from all new fields defaulting to inaccessible.
I think you can just use the Content Permissions module that comes bundled with CCK to set field-level permissions. Once you enable that module, all of your fields will appear in the Permissions area and you can deny permission to anonymous users there. I think that would be a much easier way to accomplish this.
I ran into the same problem in Drupal 6 recently, and your question is valid.
When I displayed the $form object (from template.php) using Devel's dsm() function, I found that the buttons were somehow showing a weight of 0.0111, a float.
The hook_theme() and then hook_form() in template.php seem to be behaving wrong.
Using hook_form I made no changes to the $form object, and returning drupal_render($form) the Save/Preview buttons were at the top.
To anyone that needs to use these hooks, you must ALSO create a form_alter where you set the weight of the buttons. This counteracts the bug and gets your buttons to the bottom again.
$form['buttons']['#weight'] = 100;
Note: I could not set the weight in my hook_form() code, it had to be in a form_alter