Issues for Content Construction Kit (CCK)https://www.drupal.org/project/issues/cck?text=&status=All&priorities=All&categories=All&version=All&component=All
enAdd a primary key for cluster replication supporthttps://www.drupal.org/node/2834186
<p>Was getting this, so here's a patch to add a new primary key to this database to help replicating data.</p>
<pre class="codeblock"><code class="language-php">[ERROR in query 424] Percona-XtraDB-Cluster prohibits use of DML command on a table (db.cck_field_settings) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER
</code></pre>Fri, 09 Dec 2016 00:37:09 +0000joelpittethttps://www.drupal.org/node/2834186Content copy: export form is missinghttps://www.drupal.org/node/2515502
<p>Goin to /admin/content/types/export, the form is missing, only prefix "This form will process a content type ..." is displayed.</p>
<p>Workaround:<br />
1. Edit content_copy.module and rename funtion content_copy_theme() to disabled_content_copy_theme() in line 59<br />
2. disable and re-enable content_copy module<br />
3. The form works now. Second page looks messud up, but you can proceed.</p>Wed, 01 Jul 2015 10:42:54 +0000e5segohttps://www.drupal.org/node/2515502Allow drupal_alter of nodereference allowed valueshttps://www.drupal.org/node/843832
<p>I needed to alter the options in a nodereference field with logic that goes beyond using a view. There did not seem to be any sane way to do this. By adding a drupal_alter I was able to do so cleanly.</p>Fri, 02 Jul 2010 17:20:27 +0000Jody Lynnhttps://www.drupal.org/node/843832Content Permission: Searching on CCK fields not accessible to anonymous users doesn&#039;t workhttps://www.drupal.org/node/510744
<p>CCK supports indexing of fields but ONLY if they are accessible to anonymous users.<br />
That means that if you enable <strong>Content permission</strong> and set a field as not viewable by anonymous users (for instance, to restrict access to this field to privileged users), this field won't be indexed at all, and privileged users won't be able to search on it.</p>
<p>This is because of line 768 in content.module (6.X-2.4):</p>
<pre class="codeblock"><code class="language-php"> '#access' =&gt; $formatter_name != 'hidden' &amp;&amp; content_access('view', $field),
</code></pre><p>
which should be replaced by:</p>
<pre class="codeblock"><code class="language-php"> '#access' =&gt; ($formatter_name != 'hidden') &amp;&amp; (($context == NODE_BUILD_SEARCH_INDEX) || content_access('view', $field)),
</code></pre><p>
As a matter of fact, when a scheduled cron is run, it is run as an anonymous user, so without the fix above, fields not accessible to anonymous users are not indexed.<br />
But in the other hand, if you reset indexing and run the cron manually, from admin pages, the original code above will work and fields will be indexed (this is because admin user can access anything).<br />
So as for me this is a bug: CCK fields not accessible to anonymous users are not indexed in a case and are indexed in another.<br />
All fields, whether they are accessible to anonymous users or not, should be indexed by CCK (as long as set to be from CCK display-search settings). It should then be up to "search" module to display only the results that the current user is allowed to view.</p>
<p>The fix above works for me, and I would appreciate if it could be reviewed by community.<br />
And if someone could make a patch...</p>Sun, 05 Jul 2009 16:01:35 +0000anrikunhttps://www.drupal.org/node/510744Creating default object from empty valuehttps://www.drupal.org/node/2507343
<p>I'm getting a<br />
"Creating default object from empty value " in sites\all\modules\cck\theme\theme.inc in line 135</p>
<p>using PHP 5.4 and drupal 6</p>
<p>when displaying "manage fields" in cck</p>Wed, 17 Jun 2015 08:26:11 +0000hicham7https://www.drupal.org/node/2507343Migration of filefield fields reports that this requires filefield module, even though its functionality was moved into core!https://www.drupal.org/node/1295286
<p>This seems contradicting to me!</p>
<p>The project page of emfield states:</p>
<blockquote><p>
FileField does not need a Drupal 7 version because it has been moved to Drupal Core! To upgrade FileField to Drupal 7, install the Drupal 7 CCK Package and use the Content Migrate to upgrade FileField to Drupal 7.
</p></blockquote>
<p>On the other side, the CCK "Migrate fields" assistant reports:</p>
<blockquote><p>
[…]<br /><strong>Field</strong>: field_video<br /><strong>Field type</strong>: filefield<br /><strong>Content type(s)</strong>: Text Plus, Text Plus Inline, Video<br /><strong>Other info</strong>: Missing field module: 'filefield'. This field cannot be migrated.<br />
[…]
</p></blockquote>
<h2>Manual solutions:</h2>
<ul><li><strong>Are the file / image modules enabled?</strong> Since these are new modules, they may not be enabled in your site after the upgrade. Be sure to enable them.</li>
<li>Ensure the widget_type and widget_module in the database are set properly. An example query to fix the 'llamas_pajamas' field is: <code class="language-php">update {content_node_field_instance} set widget_type = 'imagefield_widget', widget_module = 'imagefield' where field_name = 'llamas_pajamas';</code></li>
</ul>Thu, 29 Sep 2011 22:27:06 +0000porghttps://www.drupal.org/node/1295286CCK fields show up blank in node edit form after upgrading to Drupal 7https://www.drupal.org/node/1146056
<p>I am working on migrating our site from Drupal 6 to 7, using a duplicate copy of our site.</p>
<p>I followed the directions for upgrading, then installed and enabled CCK and content_migrate for Drupal 7. The fields migrate properly according to the Migrate Fields tool, but I've been running into some problems.</p>
<p>When I edit a node with fields, all the fields show up blank in the edit form. They will show up when viewing the node, but the values disappear when editing a node. This only occurs on nodes that were migrated. If I create a new node, this does not happen for that particular node.</p>
<p>I've also found that decimal fields will not even show up when viewing the node, but if I create a new node it will show up. I've checked the database and everything seems to have been migrated properly, but for some reason the values of the fields won't show up in the node edit form, and decimal field types won't show up in the node body either.</p>
<p>I tried opening the configuration page for the fields and resaving, but this didn't fix anything. Has anyone else ran into this problem? I attempted to duplicate the problem by upgrading a simple, clean install of drupal with a few fields, but everything worked in that situation.</p>Tue, 03 May 2011 20:35:28 +0000andylhansenhttps://www.drupal.org/node/1146056&quot;Description field&quot; in cck file type not migrated when using CCK Content Migratehttps://www.drupal.org/node/2787491
<p>In Drupal 6.38 I have a cck file field that is used to hold a mp3 file. I enabled the"Description field" under its settings. The "Description field" is used to "Display a text field where users may enter a description about the uploaded file." I would use this to store information about the mp3 track.</p>
<p>I am upgrading to Drupal 7.50 and using the CCK Content Migrate module.</p>
<p>When i used the CCK Content Migrate to upgrade from Drupal 6 to Drupal 7 this "Description field" data is not migrated. The "Description field" is not enabled and does not contain any data. The mp3 file path does migrate though.</p>
<p>Everything else works fine.</p>
<p>How can i get the data held in "Description field" to migrate over?</p>Sun, 21 Aug 2016 03:22:49 +0000beyond67https://www.drupal.org/node/2787491Labels for single on/off checkbox field aren&#039;t appearinghttps://www.drupal.org/node/115026
<p>I just installed the new version of cck to play around with and noticed that the labels for the new on/off checkbox field are not showing up for my new content types.</p>Thu, 01 Feb 2007 16:08:48 +0000jsenichhttps://www.drupal.org/node/115026remove trailing zeros in decimal fieldshttps://www.drupal.org/node/636382
<p>Hi,<br />
I have a decimal field set up, which contain values like 1.20, 1.25 and 1.00.<br />
Is there a way to get these values displayed as 1.2, 1.25 and 1?<br />
The default supplied formatters only seem to be capable of rounding the values to a certain unit but that's certainly no solution for me.<br />
I need to be able to get rid of the trailing (and redundant) zero's.</p>Wed, 18 Nov 2009 17:19:47 +0000shakkeihttps://www.drupal.org/node/636382D6 -&gt; D7 upgrade: Duplicate files cause Integrity constraint violation: 1062 Duplicate entry &#039;xx&#039; for key &#039;PRIMARY&#039;https://www.drupal.org/node/1176186
<p>I'm trying to migrate fields from D6-&gt;D7, and I'm using the current cck dev.</p>
<p>I originally posted this bug in a couple other forums. But all those issues appear to have been resolved. Since this issue appears to be persistent even with the latest dev I thought it deserved it's own thread.<br /><span class="project-issue-issue-link project-issue-status-info project-issue-status-7"><a href="/node/781088" title="Status: Closed (fixed)">#781088: Updating CCK Fields and Data from D6 to D7</a></span></p>
<p><strong>Scroll to the bottom for my ugly workaround</strong><br /><span class="project-issue-issue-link project-issue-status-info project-issue-status-7"><a href="/node/1157234" title="Status: Closed (fixed)">#1157234: Various PHP fatal errors, typos, etc.</a></span></p>
<p>When first running the field migration I was getting a bunch of errors, about six similar in nature to the ones below. After crawling the issue que for hits I noticed several other people mentioning problems when trying to migrate revisions. Since I don't need my revisions the first thing I did was remove all of them. Since I had already migrated from D6 I can't use this module (<a href="http://drupal.org/project/revision_deletion" rel="nofollow">http://drupal.org/project/revision_deletion</a>). Based off of that sites code I ran the following SQL commands to remove revisions.</p>
<pre class="codeblock"><code class="language-php">DELETE FROM node_revision WHERE vid NOT IN (SELECT vid FROM node)
</code></pre><p>
and I ran this for each file field</p>
<pre class="codeblock"><code class="language-php">DELETE FROM content_field_image_upload WHERE vid NOT IN (SELECT vid FROM node_revision)
</code></pre><p>
and I ran this for each node type</p>
<pre class="codeblock"><code class="language-php">DELETE FROM content_type_blog WHERE vid NOT IN (SELECT vid FROM node_revision)
</code></pre><p>
Now when I test cck field migration I receive this error.</p>
<pre class="codeblock"><code class="language-php">An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /sandboxsite4/batch?id=1991&amp;op=do StatusText: Service unavailable (with message) ResponseText: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '46' for key 'PRIMARY': INSERT INTO {file_managed} (fid, uid, filename, uri, filemime, filesize, status, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7); Array ( [:db_insert_placeholder_0] =&gt; 46 [:db_insert_placeholder_1] =&gt; 1 [:db_insert_placeholder_2] =&gt; IVAW_Bylaws_as_of_09_AUG_09.doc [:db_insert_placeholder_3] =&gt; public://IVAW_Bylaws_as_of_09_AUG_09_1.doc [:db_insert_placeholder_4] =&gt; application/msword [:db_insert_placeholder_5] =&gt; 101376 [:db_insert_placeholder_6] =&gt; 1 [:db_insert_placeholder_7] =&gt; 1269023616 ) in content_migrate_filefield_data_record_alter() (line 174 of C:\xampp\htdocs\sandboxsite4\sites\all\modules\cck\modules\content_migrate\modules\content_migrate.filefield.inc).
</code></pre><p>
I run it again and I get another similar error</p>
<pre class="codeblock"><code class="language-php">An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /sandboxsite4/batch?id=1993&amp;op=do StatusText: Service unavailable (with message) ResponseText: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '152' for key 'PRIMARY': INSERT INTO {file_managed} (fid, uid, filename, uri, filemime, filesize, status, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7); Array ( [:db_insert_placeholder_0] =&gt; 152 [:db_insert_placeholder_1] =&gt; 1 [:db_insert_placeholder_2] =&gt; media.jpg [:db_insert_placeholder_3] =&gt; public://images/header-images/media.jpg [:db_insert_placeholder_4] =&gt; image/jpeg [:db_insert_placeholder_5] =&gt; 21616 [:db_insert_placeholder_6] =&gt; 1 [:db_insert_placeholder_7] =&gt; 1270510994 ) in content_migrate_filefield_data_record_alter() (line 174 of C:\xampp\htdocs\sandboxsite4\sites\all\modules\cck\modules\content_migrate\modules\content_migrate.filefield.inc).
</code></pre><p>
I run it a third time and it completes.</p>
<p>So now I want to narrow in on the problem files causing these error's</p>
<pre class="codeblock"><code class="language-php">field_document_upload, fid 46, IVAW_Bylaws_as_of_09_AUG_09.doc
field_header_image_upload, fid 152, media.jpg
</code></pre><p>
If I go to the file's table and delete the offending FID's and then rerun cck migration, I still get errors like above. Then if you delete those new FID's in the error you get more new FID's. Since it seemed to be endless I tried something that ended up working.</p>
<p><strong>Moderate Success Achieved</strong><br />
Before migrating any fields empty your file_managed table. Now run the cck field migration. Everything should work and you should now have a bunch of files listed in the file_managed table. Copy this table and then restore your db to pre migration. What you have to do is make sure every FID listed, in that saved file_managed table, is deleted from the pre migration file_managed table. I had to delete around 60 rows. Now re-run the migration.</p>
<p>At this point you may continue to get more errors with FID's. Start writing these down. After each one shows up go in the file_managed table and delete. Then on the migration "Roll back selected fields". Now when you run it again everything will be successful or you will get another FID to record. Repeat this process until you stop receiving errors.</p>
<p>Now restore your pre-migration DB. Delete out all the offending FID's from the file_managed table. Run the CCK field migration. Now you're done!</p>
<p><em>Note: You do not need to delete revisions for this to work, but I do believe it reduced the number of FID's I ultimately had to remove.</em></p>
<p>While this isn't quick or optimal, it works. If anyone has a better/simpler solution for this, please share.</p>Thu, 02 Jun 2011 04:59:46 +0000bryancaslerhttps://www.drupal.org/node/1176186Content type export blank due to templatehttps://www.drupal.org/node/2088747
<p>The form rendered at /admin/content/types/export is always blank due to starting on step one and the 'content_copy_export_form.tpl.php' having:</p>
<pre class="codeblock"><code class="language-php">if ($form['#step'] == 2):
</code></pre>Fri, 13 Sep 2013 20:04:26 +0000b_sharpehttps://www.drupal.org/node/2088747Invalid argument supplied for foreach() https://www.drupal.org/node/237585
<p>I just attempted to create some <a href="http://drupal.org/project/daily" rel="nofollow">Daily</a> content, and after saving my node, I got the following errors:</p>
<pre class="codeblock"><code class="language-php">* warning: Invalid argument supplied for foreach() in /home/myusername/mydomain.com/sites/all/modules/cck/content.module on line 1054.
* warning: Invalid argument supplied for foreach() in /home/myusername/mydomain.com/sites/all/modules/cck/content.module on line 1094.
* warning: Invalid argument supplied for foreach() in /home/myusername/mydomain.com/sites/all/modules/cck/content.module on line 347.
</code></pre><p>
Not sure if this should be posted here in in the queue for Daily. Put it here since content.module showed. Not a big issue for me as this is just on a Test site for me. Hope it can help with future problems though!</p>Sat, 22 Mar 2008 20:11:02 +0000kriskdhttps://www.drupal.org/node/237585Unable to change widgethttps://www.drupal.org/node/361876
<p>Using the latest dev snapshot, I am unable to change the widget of an existing nodereference field. When I select a new widget and hit submit, the form simply reloads back to to the change-widget form and sets the widget select box back to whatever it was before. </p>Wed, 21 Jan 2009 05:47:48 +0000Crellhttps://www.drupal.org/node/361876Node Reference using Views returns only 1 result when there should be multipleshttps://www.drupal.org/node/529406
<p>We have a view that should be filtered by the current user logged in via an automatic argument. With the argument in place, regardless of how many results we should get back, a single result is always returned. This result is filtered correctly via the argument.</p>
<p>If I take the argument away, we do get a full list of results, of course, not "filtered" by the argument we want.</p>
<p>Noodling into the node reference module in 6.x-2.4, I did a dump of $node-&gt;result on line 852 and that result has the correct number of nodes filtered correctly by the argument. Once this is sent to $view-&gt;execute_display, however, if only returns one.</p>
<p>I am not sure if this is a Views issue because of the Views plug-in in question (content_references) or a node reference issue. It looks like the view does get the result I want, but the execute display function returned to the node reference module reduces the result set along the way.</p>Fri, 24 Jul 2009 01:55:26 +0000jthaxtonhttps://www.drupal.org/node/529406limitations CCK for contenttypehttps://www.drupal.org/node/322538
<p>hello,</p>
<p>i am working on a project where i need arround 300 CCK fields for 1 contenttype. it stops adding after 118 fields(no warnings). when i delete and add again a field everything works fine. other contenttypes can still be expanded. i searched for any limits in the code but can't find anything about it. </p>
<p>(ps: all single fields)</p>Fri, 17 Oct 2008 08:33:07 +0000rikvdhttps://www.drupal.org/node/322538Missing &#039;full&#039; display causes Fatal error: Unsupported operand types in modules/field/field.crud.inc line 598https://www.drupal.org/node/1463602
<p>The full display on one field out of 40 on my D6-&gt;D7 upgrade project is missing. content_migrate.module assumes it is available which causes an error during batch migration:</p>
<pre class="codeblock"><code class="language-php">An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /batch?id=179&amp;op=do
StatusText: OK
ResponseText:
( ! ) Fatal error: Unsupported operand types in /home/user/public_html/modules/field/field.crud.inc on line 598
Call Stack
#TimeMemoryFunctionLocation
10.0001653568{main}( )../index.php:0
20.204235797152menu_execute_active_handler( )../index.php:21
30.211537164472call_user_func_array
( )../menu.inc:517
40.211537164840system_batch_page( )../menu.inc:0
50.211537164840_batch_page( )../system.admin.inc:2333
60.211537166216_batch_do( )../batch.inc:80
70.211537166216_batch_process( )../batch.inc:161
80.214037504040call_user_func_array
( )../batch.inc:284
90.214037504104_content_migrate_batch_process_create_fields( )../batch.inc:0
100.673956899608field_create_instance( )../content_migrate.admin.inc:257
110.676556913384_field_write_instance( )../field.crud.inc:493
</code></pre><p>Solution is to check that the full display exists. Patched attached.</p>Fri, 02 Mar 2012 03:01:25 +0000eosreihttps://www.drupal.org/node/1463602Fatal error: Cannot unset string offsetshttps://www.drupal.org/node/1102822
<p>I got the error</p>
<pre class="codeblock"><code class="language-php">Fatal error: Cannot unset string offsets in /var/www/drupal/sites/all/modules/cck/content.module on line 124
</code></pre><p>
This fatal error prevents to create or edit nodes of the affected content type, so this is a major issue. I got this error with fields generated by node reference</p>
<p>More context information: <a href="http://drupal.org/node/989254" rel="nofollow">http://drupal.org/node/989254</a></p>
<p>I did a small patch to prevent this error.</p>
<p>Enjoy IT </p>Wed, 23 Mar 2011 14:50:40 +0000-enzo-https://www.drupal.org/node/1102822Strict warning when deleting a fieldhttps://www.drupal.org/node/2466551
<p>When a field is deleted the following error shows:<br /><code class="language-php">strict warning: Only variables should be passed by reference in cck/includes/content.crud.inc on line 550.</code></p>Tue, 07 Apr 2015 08:54:05 +0000DamienMcKennahttps://www.drupal.org/node/2466551On fields delete from content type shows &quot;PHP Warning : Only variables should be passed by reference&quot;https://www.drupal.org/node/2328963
<p>My host provider upgrade the version of php. current version is 5.4. Got 2 -3 issue due to this upgrade in cck.<br />
But found the patchs or fixed for most of the issues in cck issues list like this : <a href="https://www.drupal.org/node/781160" rel="nofollow">https://www.drupal.org/node/781160</a></p>
<p>But not found any path for this issue :</p>
<blockquote><p>Only variables should be passed by reference in cck\includes\content.crud.inc on line 550.</p></blockquote>
<p>This issue occur when we are going to delete any cck field from content type.</p>
<p>Issue is related to this method in \includes\content.crud file :</p>
<pre class="codeblock"><code class="language-php">&lt;?php
function content_field_instance_delete($field_name, $type_name, $rebuild = TRUE) {
include_once('./'. drupal_get_path('module', 'content') .'/includes/content.admin.inc');
// Get the previous field value.
$field = array_pop(content_field_instance_read(array('field_name' =&gt; $field_name, 'type_name' =&gt; $type_name)));
?&gt;
</code></pre><p>So working on a patch for fixing this issue, IF success post the solution here.</p>Thu, 28 Aug 2014 06:31:01 +0000rohit.wadhwahttps://www.drupal.org/node/2328963PHP warning: “Only variables should be passed by reference”https://www.drupal.org/node/781160
<p>I got the warning in includes/content.admin.inc:1283.<br />
Patch is attached.</p>Sun, 25 Apr 2010 14:24:06 +0000keinsteinhttps://www.drupal.org/node/781160display not always an array causing php error Unsupported operand types in field.crud.inchttps://www.drupal.org/node/2223957
<p>When migrating fields using content migrate on several fields I got:</p>
<p>PHP Fatal error: Unsupported operand types in /var/www/site/modules/field/field.crud.inc on line 630, referer: <a href="http://site/batch?op=start&amp;id=xxxx" rel="nofollow">http://site/batch?op=start&amp;id=xxxx</a></p>
<p>This was caused by the fact that the display types for these fields were not arrays. Unfortunately I was unable to trace which line in the content_migrate module was causing this, however I resolved it by temporarily hacking core:</p>
<p>After line 625 /modules/field/field.crud.inc I added a line:</p>
<p>foreach ($instance['display'] as $view_mode =&gt; $display) {</p>
<p>to</p>
<p>foreach ($instance['display'] as $view_mode =&gt; $display) {<br />
$display=(array)$display;</p>
<p>Hopes this helps someone dealing with similar issues.</p>Sun, 23 Mar 2014 11:16:30 +0000jkrhttps://www.drupal.org/node/2223957Text fields (textfield widget) with no max length are not being properly migrated to drupal 7 fieldshttps://www.drupal.org/node/1117028
<p>Hi,</p>
<p>I tried a D6-&gt;D7 migration with a small number of very simple content types (disabled all contributed modules, upgraded core, then enabled contributed modules one by one). The database updates went smoothly, and I ran <code class="language-php">./admin/structure/content_migrate</code>, which claimed to have successfully converted all CCK2 fields. The used field types mostly come from CCK2 core (like integer, and text fields; various optionwidgets from CCK2 core like checkboxes).</p>
<p>However, the content types can no longer be edited as on D6/CCK2; some field values, e.g. from textfield/checkboxes, are not being saved, and I'm getting lots of error messages when saving nodes:</p>
<p>Printed in red:</p>
<pre class="codeblock"><code class="language-php">Notice: Undefined index: max_length in text_field_widget_form() (line 513 of /var/www/drupal/modules/field/modules/text/text.module).
PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'field_capacity_value' at row 1: INSERT INTO {field_data_field_capacity} (entity_type, entity_id, revision_id, bundle, delta, language, field_capacity_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] =&gt; node [:db_insert_placeholder_1] =&gt; 66 [:db_insert_placeholder_2] =&gt; 66 [:db_insert_placeholder_3] =&gt; cli [:db_insert_placeholder_4] =&gt; 0 [:db_insert_placeholder_5] =&gt; und [:db_insert_placeholder_6] =&gt; ) in field_sql_storage_field_storage_write() (line 425 of /var/www/drupal/modules/field/modules/field_sql_storage/field_sql_storage.module).
</code></pre><p>
On the bottom: "The website encountered an unexpected error. Please try again later."</p>
<p>Additionally, I'm getting this red notice when viewing a node:</p>
<pre class="codeblock"><code class="language-php">Notice: Undefined index: max_length in text_field_widget_form() (line 513 of /var/www/drupal/modules/field/modules/text/text.module).
</code></pre><p>
And yes, newly created nodes are being saved, but usually do not contain the values from checkboxes, or texts entered in textfields. Also I noticed that i can not change existing checkbox values when editing an existing node; I can click on (another) checkbox, but this value isn't saved, either.</p>
<p>The field configuration at <code class="language-php">./admin/structure/types</code> was - at least in some cases - changed significantly; e.g., I wasn't using key|value pairs, just values; those became key|value pairs like</p>
<pre class="codeblock"><code class="language-php">1|value1
2|value2
...
</code></pre><p>
Also, defined minimum/maximum values for integer number disappeared during the CCK field migration.</p>
<p>Please advise if I'm posting in the wrong issue queue, but I really do not know where issues like this belong (fields in core? CCK migration?).</p>
<p>Thanks &amp; greetings, -asb</p>Tue, 05 Apr 2011 15:55:11 +0000asbhttps://www.drupal.org/node/1117028Converted numeric fields cause SQL error on inserthttps://www.drupal.org/node/2679491
<p>Converted numerical CCK fields that have no default and are not mandatory cause the following SQL exception in PostgreSQL backend, when they are left blank:</p>
<p>PDOException: SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for type numeric: "" LINE 1: ...ode', '761498', '761503', 'rnai_experiment', '0', 'und', '') ^: INSERT INTO field_data_field_fragment_concentration (entity_type, entity_id, revision_id, bundle, delta, language, field_fragment_concentration_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( ) in field_sql_storage_field_storage_write() (line 514 of modules/field/modules/field_sql_storage/field_sql_storage.module).</p>
<p>In this example field_data_field_fragment_concentration is a decimal field that was converted from a CCK field, that had no default and was not mandatory. The field settings cannot be changed because the field contains data. </p>
<p>Possible reason: the database back-end trying to store empty numeric values as an empty string instead of NULL.<br />
Storing numeric fields works ok for new content types (made in D7, not migrated)</p>
<p>Major because, makes non-mandatory non-default fields not usable for converted data, and trying to submit causes a server-error.</p>Wed, 02 Mar 2016 13:46:23 +0000LiceBaseAdminhttps://www.drupal.org/node/2679491Problem with field visibility after upgrade using Content Migratehttps://www.drupal.org/node/2654788
<p>I'm the maintainer of the <a href="/project/metis" rel="nofollow">Metis module</a> and I just released a D7 version of the module. It uses a CCK field (D6) or a core field (D7) to save some data in a text field. For that reason I use the CCK's content migrate module to migrate the content of the field. It seems to work fine, but there is a strange thing happening regarding the field's visibility:</p>
<p>After the upgrade the field isn't rendered until I visit the content type's display settings page (<code class="language-php">admin/structure/types/manage/[content_type]/display/default</code>), move the field, and save.</p>
<p>I investigated and found out that doing so, something is changed in the field's visibility settings. These are parts of the results of <code class="language-php">var_export(field_info_instance('node', 'field_metis', '[content_type]'));</code> before and after saving the display settings page:</p>
<p>BEFORE:</p>
<pre class="codeblock"><code class="language-php"> 'default' =&gt;
array (
'label' =&gt; 'hidden',
'type' =&gt; 'taxonomy_term_reference_plain',
'weight' =&gt; '22',
'settings' =&gt;
array (
),
'module' =&gt; 'taxonomy',
),
</code></pre><p>
AFTER:</p>
<pre class="codeblock"><code class="language-php"> 'default' =&gt;
array (
'label' =&gt; 'hidden',
'type' =&gt; 'metis_default',
'weight' =&gt; '13',
'settings' =&gt;
array (
),
'module' =&gt; 'metis',
),
</code></pre><p>
Now I'm wondering if that <code class="language-php">taxonomy_term_reference_plain</code> is due to an error in the Content Migrate module or if I need to change something in the Metis module to make the upgrade work smoothly. Can you help?</p>Fri, 22 Jan 2016 08:27:12 +0000yanhttps://www.drupal.org/node/2654788Broken link on project pagehttps://www.drupal.org/node/2680387
<p>The link to the blog post about migration multi groups to field collections is broken. </p>
<p>Broken URL<br /><a href="https://www.urbaninsight.com/blog/2012/02/28/migrating-drupal-6-multigroups-drupal-7-field-collections" rel="nofollow">https://www.urbaninsight.com/blog/2012/02/28/migrating-drupal-6-multigro...</a></p>
<p>Working URL<br /><a href="https://www.urbaninsight.com/2012/02/28/migrating-drupal-6-multigroups-drupal-7-field-collections" rel="nofollow">https://www.urbaninsight.com/2012/02/28/migrating-drupal-6-multigroups-d...</a></p>Thu, 03 Mar 2016 15:59:00 +0000bburghttps://www.drupal.org/node/2680387Migration of a D6 optionwidgets text fields to D7 leads to server reset on node displayhttps://www.drupal.org/node/2665208
<p>I am trying to migrate my CCK types in D6 to D7 Fields using content_migrate, so far, all except one type could be migrated. When I migrate a cck field of type text using an optionswidget in D6, trying to display the node in D7 results in a server reset: </p>
<p>In Chrome the message is "No data received ERR_EMPTY_RESPONSE", Firefox says "Secure Connection Failed The connection to the server was reset while the page was loading". The server log is completely empty for loading this page, so I guess php dies pretty early. </p>
<p>I have tracked this down to exactly this optionwidgets field by rolling back and migrating all fields 20+ one by one, no other field type causes such behaviour.</p>
<p>Some interesting detail: Rolling back the field in drush will immediately display the page in the Browser, without needing to reload the page. (Ajax?)</p>
<pre class="codeblock"><code class="language-php">field_sex list_text RNAi Changed field type: The 'field_sex' field uses a 'optionwidgets_buttons' widget.
The field type will be changed from 'text' to 'list_text'.
</code></pre><p>
This is the output of from the migration process of this field:</p>
<pre class="codeblock"><code class="language-php">Changed field type: The 'field_sex' field uses a 'optionwidgets_buttons' widget. The field type will be changed from 'text' to 'list_text'.
Created field field_sex
Created instance of field_sex in bundle RNAi.
</code></pre><p>
The behavior can be fully each time reproduced by rolling back this field (node works again), and re-migrating (server error). So I am quite sure it depends on the migrated options field. I do not see a server reset anywhere else on my migrated site.</p>
<p>More details about what I have tried: </p>
<ul><li>I have checked the configuration of the generated option field at admin/structure/types/manage/rnai-experiment/fields/field_sex<br />
It looks normal.</li>
<li>I have created a new content type in D7 using an options field with check boxed, that worked</li>
<li>I have compared fields_data_field_ and fields_revisions_field_ entries for the nodes that do not work with the new options, they look good</li>
<li>cleared the caches, no pending dbupdates, disabled-enabled the options module, vacuumed the database</li>
<li>enabled all debugging output in the Devel module (kromo) including queries</li>
</ul><p>I hope someone can help me because I am completely out of options, and I cannot complete the migration without the data. Any pointer, workaround, or hint on how to debug this is very welcome. Please let me know if any more information is required.</p>
<p>More details below:<br />
----------------------------------------------------------------------------------<br />
This is run on a Centos 6 cloned test instance from the production, Apache/2.2.15 (Unix), PHP 5.3, <strong>PostgreSQL 8.4</strong>, updates completed, no pending db updates,<br />
this is a <strong>Tripal</strong> instance. Core Options Enabled 7.41, CCK version 7.x-3.0-alpha3, I can add a full module list if that is required.</p>
<p>Following some SQL queries for one of the affected nodes, it looks very normal:</p>
<pre class="codeblock"><code class="language-php">d7=# select * from node_revision where nid = 761442;
nid | vid | uid | title | log | timestamp | status | comment | promote | sticky
--------+--------+-----+------------------+-----+------------+--------+---------+---------+--------
761442 | 761447 | 39 | Neverland AD F 1 | | 1447762864 | 1 | 2 | 0 | 0
d7=# select * from field_data_field_sex where entity_id = 761442;
entity_type | bundle | deleted | entity_id | revision_id | language | delta | field_sex_value
-------------+-----------------+---------+-----------+-------------+----------+-------+-----------------
node | rnai_experiment | 0 | 761442 | 761447 | und | 0 | female
d7=# select * from field_revision_field_sex where entity_id = 761442;
entity_type | bundle | deleted | entity_id | revision_id | language | delta | field_sex_value
-------------+-----------------+---------+-----------+-------------+----------+-------+-----------------
node | rnai_experiment | 0 | 761442 | 761447 | und | 0 | female
</code></pre><p>
Settings of this field at:</p>
<p>admin/structure/types/manage/rnai-experiment/fields/field_sex<br />
--------------------------------------------------------<br />
Label *: Sex</p>
<p>Required field</p>
<p>Help text: Enter the sex of the sample organism, if applicable.</p>
<p>DEFAULT VALUE: None</p>
<p>Field visibility and permissions: Public</p>
<p>Number of values: 1</p>
<p>Allowed values list:<br />
female|female<br />
male|male<br />
both|both<br />
unknown|unknown</p>
<p>Edit: adding the dblog output for loading the page for which the server responds with no data.</p>
<p>/admin/reports/dblog<br />
-----------------------------------------------------------------------------<br />
Notice: Undefined index: granularity in date_formatter_process() (line 250 of /home/licebase/d7/sites/all/modules/date/date.module).<br />
Notice: Undefined index: todate in date_process_values() (line 358 of /home/licebase/d7/sites/all/modules/date/date.module).<br />
Notice: Undefined index: tz_handling in date_formatter_process() (line 233 of /home/licebase/d7/sites/all/modules/date/date.module).<br />
Notice: Undefined index: granularity in date_granularity() (line 347 of /home/licebase/d7/sites/all/modules/date/date.module).<br />
Notice: Undefined index: access in user_reference_field_formatter_prepare_view() (line 392 of /home/licebase/d7/sites/all/modules/references/user_reference/user_reference.module).<br />
Notice: Undefined index: access in user_reference_field_formatter_prepare_view() (line 380 of /home/licebase/d7/sites/all/modules/references/user_reference/user_reference.module).<br />
Notice: Undefined index: access in node_reference_field_formatter_prepare_view() (line 408 of /home/licebase/d7/sites/all/modules/references/node_reference/node_reference.module).<br />
Notice: Undefined index: access in node_reference_field_formatter_prepare_view() (line 396 of /home/licebase/d7/sites/all/modules/references/node_reference/node_reference.module).</p>
<p>That is the only output that I could find so far that is generated during page loading.</p>Tue, 09 Feb 2016 10:29:01 +0000LiceBaseAdminhttps://www.drupal.org/node/2665208Create upgrade path for Multigroupshttps://www.drupal.org/node/1056188
<p>We need to start to identify the upgrade path for Multigroup data. You can upgrade the individual field data as separate fields, but you will lose any synchronization of the values across fields. And if you have empty values they will get collapsed out.</p>
<p>Either <a href="http://drupal.org/project/field_group" rel="nofollow">Field group</a> module or <a href="http://drupal.org/project/field_collection" rel="nofollow">Field collection</a> module are likely candidates, but there may be others.</p>
<p>What has to be done is this:</p>
<p>1) Create something equivalent to the multigroup using one of the D7 modules.<br />
2) Figure out how you would map the data in the D6 tables to what you created in D7.<br />
3) Write a patch that would handle that.</p>Wed, 09 Feb 2011 13:12:24 +0000KarenShttps://www.drupal.org/node/1056188Problem afterwards with migrated integer or nodereference field when emptyhttps://www.drupal.org/node/1431524
<p>I still have problem with integer fields I've migrated.<br />
Fields are not required. When I create a new node, if I leave the field empty I have that pdo exception</p>
<p>PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'field_altitude_bas_value' at row 1: INSERT INTO {field_data_field_altitude_bas} (entity_type, entity_id, revision_id, bundle, delta, language, field_altitude_bas_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] =&gt; node [:db_insert_placeholder_1] =&gt; 2904 [:db_insert_placeholder_2] =&gt; 2904 [:db_insert_placeholder_3] =&gt; bisse [:db_insert_placeholder_4] =&gt; 0 [:db_insert_placeholder_5] =&gt; und [:db_insert_placeholder_6] =&gt; ) in field_sql_storage_field_storage_write() (line 448 of C:\Program Files (x86)\EasyPHP-5.3.8.1\www\cms\mdbMig50\modules\field\modules\field_sql_storage\field_sql_storage.module).</p>
<p>In fact, Drupal is trying to create a record in table field_data_field_xxx with value blank or something illegal.<br />
Normally, for new field integer or noderef created in D7, when field stay empty or nothing is selected in select list, Drupal does not create a record.</p>
<p>This problem make it impossible to migrate from D6 to D7 if we have node reference fields that are not required.</p>Tue, 07 Feb 2012 15:42:14 +0000sahunihttps://www.drupal.org/node/1431524Strict warning: Declaration should be compatiblehttps://www.drupal.org/node/1962718
<p>CCK with PHP 5.4 creates error messages like this:</p>
<blockquote><p>Declaration of content_handler_field_multiple::pre_render() should be compatible with views_handler_field::pre_render(&amp;$values) in modules/cck/includes/views/handlers/content_handler_field_multiple.inc</p></blockquote>
<p>To fix it, in content_handler_field_multiple.inc, replace<br /><code class="language-php">function pre_render($values) {</code><br />
with<br /><code class="language-php">function pre_render(&amp;$values) {</code></p>Fri, 05 Apr 2013 19:47:08 +0000SeanAhttps://www.drupal.org/node/1962718userreference for version 3https://www.drupal.org/node/2629316
<p>Hey guys,</p>
<p>I'm trying to migrate a client's site from D6 to D7 and it's telling me it cannot migrate userreference fields because: Missing field module: 'userreference'. This field cannot be migrated.</p>
<p>I saw a previous post saying this was fixed in version 2, what happened with version 3?</p>
<p>Thanks.</p>Sat, 05 Dec 2015 02:56:43 +0000jfha73https://www.drupal.org/node/2629316multiple values in viewshttps://www.drupal.org/node/556232
<p>hi all!</p>
<p>i've been searching for the last hour, and havent been able to find anything too similar to this, so i figured i should ask for some help.</p>
<p>i'm building a band website for a friend. one of the content types is called "record," for each record they put out. now, bands release albums in different formats, so one of the fields i created was a multi value check box called "format." the available "formats" are CD, VINYL, CASSETTE (yes, some labels still put out cassettes!) and digital downloads.</p>
<p>in Views, i created a field view that lists the available format. </p>
<p>this is what it looks like:<br />
CD<br />
VINYL<br />
CASSETTE</p>
<p>but this is what i'd LIKE it to look like:<br />
CD/VINYL/CASSETTE</p>
<p>so to sum up, i'd like to group multiple value fields into a single row, and insert slashes or comma's between the values if there is more than 1.</p>Sat, 22 Aug 2009 00:05:41 +0000hunterchristyhttps://www.drupal.org/node/556232Outdated link on module pagehttps://www.drupal.org/node/2623748
<p>Urbaninsight link is wrong on the module page. Should be <a href="https://www.urbaninsight.com/2012/02/28/migrating-drupal-6-multigroups-drupal-7-field-collections" rel="nofollow">https://www.urbaninsight.com/2012/02/28/migrating-drupal-6-multigroups-d...</a></p>Thu, 26 Nov 2015 15:00:15 +0000kari.kaariainenhttps://www.drupal.org/node/2623748E_STRICT compliancehttps://www.drupal.org/node/2327005
<p>This is a small patch against 6.x-3.x to some views handler declarations, to prevent the warnings below when in an E_STRICT environment, such as PHP 5.4.</p>
<p>As necessity and opportunity allow, I hope to keep this this comprehensive and freshly rolled. I encourage others to post additional patches here, if they find further E_STRICT warnings, wherever they may be.</p>
<blockquote><p>content_handler_field::element_type() should be compatible with views_handler_field::element_type($none_supported = false, $default_empty = false, $inline = false) in cck\includes\views\handlers\content_handler_field.inc on line 228.</p>
<p>Declaration of content_handler_field_multiple::query() should be compatible with views_handler_field::query($group_by = false) in cck\includes\views\handlers\content_handler_field_multiple.inc on line 321.</p>
<p>Declaration of content_handler_field_multiple::pre_render() should be compatible with views_handler_field::pre_render(&amp;$values) in cck\includes\views\handlers\content_handler_field_multiple.inc on line 321.</p>
<p>Declaration of content_handler_field_multiple::element_type() should be compatible with content_handler_field::element_type($none_supported = false, $default_empty = false, $inline = false) in cck\includes\views\handlers\content_handler_field_multiple.inc on line 321.
</p></blockquote>Mon, 25 Aug 2014 01:45:24 +0000mw4ll4c3https://www.drupal.org/node/2327005Notice : Only variable references should be returned by reference line 2857 content.modulehttps://www.drupal.org/node/1716932
<p>When I create a new node during simpletest I have this notice.</p>
<p>Apache : 2.2<br />
PHP mode : Apache Module (mod_php)<br />
PHP : 5.3.9</p>Tue, 07 Aug 2012 10:02:15 +0000underqhttps://www.drupal.org/node/1716932Cannot edit content type settingshttps://www.drupal.org/node/2621972
<p><a href="http://techmallu.com/error.jpg" rel="nofollow">http://techmallu.com/error.jpg</a></p>
<p>Please see the image and help me.</p>Tue, 24 Nov 2015 10:57:18 +0000kuttu666https://www.drupal.org/node/2621972Upgrade from 7.x-2.x-dev to 7.x-3.0-alpha3https://www.drupal.org/node/2620350
<p>Is it safe to upgrade from 7.x-2.x-dev to 7.x-3.0-alpha3?</p>Sat, 21 Nov 2015 03:14:57 +0000drupalismehttps://www.drupal.org/node/2620350CCK Multigroup Cache Issuehttps://www.drupal.org/node/2617442
<p>I am using CCK multigroup (ver 6.x-3.0-alpha4+0-dev) with multistep (ver 6.x-1.5) module. This working fine in the dev server. But in the production server, I getting some issue. When click on "Add more values" button, it returns empty. I debugged that, I found that "form_get_cache" returning empty.</p>
<p>I set #cache = TRUE in the node form, but still getting the issue. Fighting over 4/5 days, have no clue how to fix it. Please somebody help me.</p>
<p>I am using Drupal 6.37.<br />
CCK multigroup - 6.x-3.0-alpha4+0-dev<br />
multistep - 6.x-1.5</p>
<p>Moreover,<br />
-I set field default values for multigroup fields, that default values are not showing.<br />
-Tried to hide None value, automatically displayed when click on "Add more values" button</p>
<p>thanks in advance</p>Tue, 17 Nov 2015 18:01:43 +0000shafiqhossainhttps://www.drupal.org/node/2617442Create arrays of dates in CCK listhttps://www.drupal.org/node/2606182
<p>I want to create a list of dates in a CCK select list with PHP arrays.</p>
<p>Is this possible to do with any known module? I don't want to use Date.module. Views maybe?</p>
<p>I don't have any luck with this, any help is appreciated.</p>
<p>Minimum date: +4 days<br />
Maximum date: +2 months<br />
Only bussines days (Mon-Fri)</p>
<p>And I also would like to display the dates in the following format if it's possible: "Mon 5 Nov."</p>
<p>Thanks!!</p>Mon, 02 Nov 2015 09:01:58 +0000Patrick Danielssonhttps://www.drupal.org/node/2606182Strict warning: Declaration of content_handler_field_multiple::pre_render() should be compatible with views_handler_field::pre_render(&amp;$values)https://www.drupal.org/node/2599736
<p>There is a problem with pre_render method.</p>
<p>Patch in the next comment.</p>Fri, 23 Oct 2015 12:36:37 +0000jansetehttps://www.drupal.org/node/2599736Unable to migrate number fieldshttps://www.drupal.org/node/1099950
<p>Drupal 6.x install that is upgraded to D7. Running latest CCK 7.x-dev.<br />
Unable to migrate simple integer number fields. Have multiple number fields but I not able to get them migrated. Other fields like text, date, email etc. all migrated OK. </p>
<p>field_number (number_integer)</p>
<p>PHP Fatal error: Unsupported operand types in /Users/steinmb/htdocs/sites/elmcip.net/drupal7_versjon/drupal/modules/field/field.crud.inc on line 601<br />
PHP Stack trace:<br />
PHP 1. {main}() /Users/steinmb/htdocs/sites/elmcip.net/drupal7_versjon/drupal/index.php:0<br />
PHP 2. menu_execute_active_handler() /Users/steinmb/htdocs/sites/elmcip.net/drupal7_versjon/drupal/index.php:22<br />
PHP 3. call_user_func_array() /Users/steinmb/htdocs/sites/elmcip.net/drupal7_versjon/drupal/includes/menu.inc:501<br />
PHP 4. system_batch_page() /Users/steinmb/htdocs/sites/elmcip.net/drupal7_versjon/drupal/includes/menu.inc:0<br />
PHP 5. _batch_page() /Users/steinmb/htdocs/sites/elmcip.net/drupal7_versjon/drupal/modules/system/system.admin.inc:2282<br />
PHP 6. _batch_do() /Users/steinmb/htdocs/sites/elmcip.net/drupal7_versjon/drupal/includes/batch.inc:81<br />
PHP 7. _batch_process() /Users/steinmb/htdocs/sites/elmcip.net/drupal7_versjon/drupal/includes/batch.inc:162<br />
PHP 8. call_user_func_array() /Users/steinmb/htdocs/sites/elmcip.net/drupal7_versjon/drupal/includes/batch.inc:285<br />
PHP 9. _content_migrate_batch_process_create_fields() /Users/steinmb/htdocs/sites/elmcip.net/drupal7_versjon/drupal/includes/batch.inc:0<br />
PHP 10. field_create_instance() /Users/steinmb/htdocs/sites/elmcip.net/drupal7_versjon/drupal/sites/all/modules/cck/modules/content_migrate/includes/content_migrate.admin.inc:229<br />
PHP 11. _field_write_instance() /Users/steinmb/htdocs/sites/elmcip.net/drupal7_versjon/drupal/modules/field/field.crud.inc:491</p>
<p>Any ideas on where to start digging?</p>Mon, 21 Mar 2011 11:08:55 +0000steinmbhttps://www.drupal.org/node/1099950Update from D5 -&gt; D6 -&gt; D7https://www.drupal.org/node/1997182
<p>Ok, so, I cannot reproduce this but in a client setup. D5 to D6 is ok, no problems in there but, once I try to migrate two of the multiple fields I have:</p>
<ul><li>1st - field_news_bilder file News Changed field type: The 'field_news_bilder' field type will be changed from 'filefield' to 'file'.<br />Missing formatter: The 'image_plain' formatter used in 2 view modes for the field_news_bilder field is not available, these displays will be reset to the default formatter.<br />Missing formatter: The '' formatter used in 1 view modes for the field_news_bilder field is not available, these displays will be reset to the default formatter.
</li>
<li>2nd- Details field_bilder file Page Projekt Caution: The 'field_bilder' field is a shared field that uses different widgets. The 'filefield_widget' widget is sometimes used to determine the destination field type for the new field. The migration may not work correctly if other widgets used by this shared field would create different results.<br />Changed field type: The 'field_bilder' field type will be changed from 'filefield' to 'file'.<br />Missing widget: The 'image' widget is not available for the field_bilder field, it will be set to the default widget.<br />Missing formatter: The '' formatter used in 1 view modes for the field_bilder field is not available, these displays will be reset to the default formatter.<br />Missing formatter: The 'image_plain' formatter used in 2 view modes for the field_bilder field is not available, these displays will be reset to the default formatter.<br />Missing formatter: The '' formatter used in 1 view modes for the field_bilder field is not available, these displays will be reset to the default formatter.
</li>
</ul><p>It gives the following result (the scripts seam to be interrupted):</p>
<p>Migrating data</p>
<p>Field migration has encountered an error.<br />
Please continue to the error page<br />
An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /projects/7.x/batch?id=8&amp;op=do StatusText: Internal Server Error ResponseText: </p>
<p>Since nothing else is present on the Error Response, I have analysed the logs:</p>
<ul><li>
Typ PHP<br />
Datum Freitag, May 17, 2013 - 11:44<br />
Benutzer admin<br />
Ort <a href="http://192.168.50.62/projects/7.x/admin/structure/content_migrate" rel="nofollow">http://192.168.50.62/projects/7.x/admin/structure/content_migrate</a><br />
Referrer <a href="http://192.168.50.62/projects/7.x/batch?op=start&amp;id=7" rel="nofollow">http://192.168.50.62/projects/7.x/batch?op=start&amp;id=7</a><br />
Nachricht Notice: Undefined index: label in _content_migrate_get_instance_values() (line 177 of /var/www/projects/7.x/sites/all/modules/cck/modules/content_migrate/includes/content_migrate.values.inc).<br />
Schweregrad Mitteilung<br />
Hostadresse 192.168.50.45<br />
Operationen
</li>
<li>
Typ PHP<br />
Datum Freitag, May 17, 2013 - 11:44<br />
Benutzer admin<br />
Ort <a href="http://192.168.50.62/projects/7.x/admin/structure/content_migrate" rel="nofollow">http://192.168.50.62/projects/7.x/admin/structure/content_migrate</a><br />
Referrer <a href="http://192.168.50.62/projects/7.x/batch?op=start&amp;id=7" rel="nofollow">http://192.168.50.62/projects/7.x/batch?op=start&amp;id=7</a><br />
Nachricht Notice: Undefined index: full in _content_migrate_get_instance_values() (line 231 of /var/www/projects/7.x/sites/all/modules/cck/modules/content_migrate/includes/content_migrate.values.inc).<br />
Schweregrad Mitteilung<br />
Hostadresse 192.168.50.45<br />
Operationen
</li>
<li>
Typ PHP<br />
Datum Freitag, May 17, 2013 - 11:44<br />
Benutzer admin<br />
Ort <a href="http://192.168.50.62/projects/7.x/admin/structure/content_migrate" rel="nofollow">http://192.168.50.62/projects/7.x/admin/structure/content_migrate</a><br />
Referrer <a href="http://192.168.50.62/projects/7.x/batch?op=start&amp;id=7" rel="nofollow">http://192.168.50.62/projects/7.x/batch?op=start&amp;id=7</a><br />
Nachricht Notice: Undefined index: max_filesize_per_file in content_migrate_filefield_instance_alter() (line 193 of /var/www/projects/7.x/sites/all/modules/cck/modules/content_migrate/modules/content_migrate.filefield.inc).<br />
Schweregrad Mitteilung<br />
Hostadresse 192.168.50.45<br />
Operationen
</li>
</ul><p>Some help would be awesome. I've tried the code changes in <a href="http://drupal.org/files/cck-remove_php_notice_max_filesize_per_file.patch" rel="nofollow">http://drupal.org/files/cck-remove_php_notice_max_filesize_per_file.patch</a> and <a href="http://drupal.org/files/cck-remove_php_notice_list_field.patch" rel="nofollow">http://drupal.org/files/cck-remove_php_notice_list_field.patch</a> with no positive outcome, and the errors are the same.</p>
<p>Hope this can be figured out soon!</p>
<p>*edit: sorry about the title... didn't knew what to put</p>Fri, 17 May 2013 11:56:34 +0000nmpribeirohttps://www.drupal.org/node/1997182Can anyone help me with CCK migration errors? (D6 to D7 upgrade)https://www.drupal.org/node/2260471
<p>I have tried migrating my CCK data from a Drupal 6 site to a Drupal 7 site. I tried migrating just one field, though I have 7 fields that have to be migrated for me to consider this upgrade process a success. If you're willing I'd like to get assistance with each of these errors one field at a time as I go through this extremely difficult process. I have researched these matters to the point of feeling like my head is going to explode and cannot find working solutions in what I have read so far. So I am very much in need of guru level guidance from someone that has been through this process before. </p>
<p>I'm currently trying to find a fix for the unlimited length field using a textfield widget error.</p>
<p>---------------------------------------------------------------------------<br />
[this part is in green]</p>
<p>Migrate fields<br />
Status message</p>
<p> Operating in maintenance mode. Go online.<br />
Rolling back field_website_url.</p>
<p>---------------------------------------------------------------------------<br />
[this part is in yellow]</p>
<p>Warning message</p>
<p> Invalid field/widget combination: The field 'field_website_url' in the bundle 'partner' is an unlimited length field using a textfield widget, not allowed in D7. The field length will be set to 255.<br />
Created field field_website_url<br />
Missing formatter: The 'text_hidden' formatter used in 3 view modes for the field_website_url field is not available, these displays will be reset to the default formatter.<br />
Created instance of field_website_url in bundle Partner.</p>
<p>----------------------------------------------------------------------------<br />
[this part is in red]</p>
<p>Error message</p>
<p> Requesting rollback of field "field_website_url" due to failure to convert record:</p>
<p> array ( 'entity_id' =&gt; '9', 'revision_id' =&gt; '9', 'field_website_url_value' =&gt; [value removed, but I believe it is flagged because it is longer than 255 characters], 'field_website_url_format' =&gt; '2', 'entity_type' =&gt; 'node', 'language' =&gt; 'und', 'delta' =&gt; '0', 'bundle' =&gt; 'partner', )</p>
<p> Cause:</p>
<p> exception 'PDOException' with message 'SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'field_website_url_value' at row 1' in [path removed]/includes/database/database.inc:2168 Stack trace: #0 [path removed]/includes/database/database.inc(2168): PDOStatement-&gt;execute(Array) #1 [path removed]/includes/database/database.inc(680): DatabaseStatementBase-&gt;execute(Array, Array) #2 [path removed]/includes/database/mysql/query.inc(36): DatabaseConnection-&gt;query('INSERT INTO {fi...', Array, Array) #3 [path removed]/includes/common.inc(7194): InsertQuery_mysql-&gt;execute() #4 [path removed]/sites/all/modules/cck/modules/content_migrate/includes/content_migrate.admin.inc(432): drupal_write_record('field_data_fiel...', Array) #5 [internal function]: _content_migrate_batch_process_migrate_data('field_website_u...', Array) #6 [path removed]/includes/batch.inc(284): call_user_func_array('_content_migrat...', Array) #7 [path removed]/includes/batch.inc(161): _batch_process() #8 [path removed]/includes/batch.inc(80): _batch_do() #9 [path removed]/modules/system/system.admin.inc(2365): _batch_page() #10 [internal function]: system_batch_page() #11 [path removed]/includes/menu.inc(517): call_user_func_array('system_batch_pa...', Array) #12 [path removed]/index.php(21): menu_execute_active_handler() #13 {main}</p>
<p>[There are 6 errors like this, so I'm assuming that means that only 6 of my nodes using this field have data in this field that is more than 255 characters long, but the others are all under 255, so the others did not generate these errors.]<br />
--------------------------------------------------------------------------------------------<br />
[this is what shows in available fields for this field I'm starting with]</p>
<p> field_website_url text </p>
<p> Partner</p>
<p> Invalid field/widget combination: The field 'field_website_url' in the bundle 'partner' is an unlimited length field using a textfield widget, not allowed in D7. The field length will be set to 255.<br />
Missing formatter: The 'text_hidden' formatter used in 3 view modes for the field_website_url field is not available, these displays will be reset to the default formatter.</p>
<p>--------------------------------------------------------------------------------------------</p>
<p>I'd like to solve this textfield widget matter first because that seems to be the one that is stopping this migrate from working. If that matter is resolved, I do not know the 'text_hidden' formatter issue will stop the migration from happening. Note that if the field data gets truncated to 255 and I lose data on these 6 nodes, that is acceptable to me if it means I will get the data successfully imported into all the other nodes of this type. There are nearly 300 nodes using this field on this site, so it will be a major pain to have to recreate all of this manually. If these 6 fields show only the first 255 characters of data after an otherwise successful migration, I can then go into those nodes and just edit these 6 instances of this field to have less characters. That will not be problematic as there are characters in this field on these nodes that can be removed.</p>
<p>If need be, I'd be fine with just editing the MySQL database as needed to change the field length in there, if that is an option, but I do not know how to do this. I would just need instruction for doing that, which would get me a workaround needed if a module fix for this is impossible in a timely manner. I'm on a very tight timeline for getting this site migration from Drupal 6 to Drupal 7 done because there is a limited time for how long our hosting provider is going to maintain anything lower than PHP 5.4 and I have to get 12 different websites upgraded quickly. So any quick workarounds in the MySQL database that will get me past these errors would be fine if you could just provide me with specific instructions on what needs to be done.</p>
<p>Note that I've already upgraded the site from D6 to D7 in all aspects except for these CCK migration problems. I'd much prefer solutions within this D7 version, rather than rolling back to the D6 version and starting the upgrade process over from scratch again, if at all possible. I don't mind rolling back to the D6 version if absolutely necessary though.</p>
<p>Thanks for any assistance you can provide on this issue.</p>Wed, 07 May 2014 08:34:43 +0000wildlifehttps://www.drupal.org/node/2260471ckk error when upgreading from d6 to D7https://www.drupal.org/node/2501317
<p>I tried to upgrade drupal from 6 to 7 just overwriting files and disabling core moduels and then pressing update but I got this huge error so dunno what is going on</p>
<p>An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: <a href="https://www.ww.com/wwmigrationubercart67/update.php?op=selection&amp;token=i" rel="nofollow">https://www.ww.com/wwmigrationubercart67/update.php?op=selection&amp;token=i</a>... StatusText: Service unavailable (with message) ResponseText: Recoverable fatal error: Argument 2 passed to db_query() must be of the type array, string given, called in /home/ww/public_html/wwmigrationubercart67/modules/cck/content.module on line 596 and defined in db_query() (line 2345 of /home/ww/public_html/ww/includes/database/database.inc)</p>Fri, 05 Jun 2015 19:01:54 +0000https://www.drupal.org/node/2501317filefield convert into file migrate from d6 to d7 ERRORhttps://www.drupal.org/node/2489996
<p>HI,</p>
<p>I tried migrating using content migrate with the fields, and it stucked on the error :</p>
<pre class="codeblock"><code class="language-php">Requesting rollback of field "field_evt_mat_download" due to failure to convert record:
array ( 'entity_id' =&gt; '4715', 'revision_id' =&gt; '4742', 'field_evt_mat_download_fid' =&gt; '9109', 'field_evt_mat_download_data' =&gt; 'a:1:{s:11:"description";s:32:"Presentation (Open as Read Only)";}', 'delta' =&gt; '8', 'entity_type' =&gt; 'node', 'language' =&gt; 'und', 'bundle' =&gt; 'event', 'field_evt_mat_download_description' =&gt; 'Presentation (Open as Read Only)', 'field_evt_mat_download_display' =&gt; '1', )
Cause:
exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'public://local marketing/event/member-appreciation-october/2012/' for key 'uri'' in D:\xampp\htdocs\aadev\dev7\includes\database\database.inc:2171 Stack trace: #0 D:\xampp\htdocs\aadev\dev7\includes\database\database.inc(2171): PDOStatement-&gt;execute(Array) #1
</code></pre><p>
but the field was then moved into the converted fields section, so I assumed its partially migrated, but when I checked into the content type, the current fields are not showing at all,</p>
<p>why is that happening, and is there anyway I can solve it?</p>
<p>help please thank you!</p>Sat, 16 May 2015 21:24:09 +0000boby uihttps://www.drupal.org/node/2489996Plan for CCK 7.x-3.0 releasehttps://www.drupal.org/node/1277262
<p>So this module is a bit odd, since it basically contains only the field migrate code. However, right now the only way to get at this code is through a 7.x-2.x-*dev* release, which is basically terrifying to any average person, regardless of how well it might work. :\</p>
<p><a href="http://drupal.org/project/issues/cck?version=7.x" rel="nofollow">http://drupal.org/project/issues/cck?version=7.x</a> paints actually a pretty rosy picture; apart from the multigroup update path, there aren't any other critical issues. <span class="project-issue-issue-link project-issue-status-info project-issue-status-7"><a href="/node/1262808" title="Status: Closed (fixed)">#1262808: Performance for content_migrate field data</a></span> looks like a really nice performance improvement, too.</p>
<p>Porting status of contrib is cited as the #1 reason people aren't adopting D7, so a stable release of CCK would be awesome. I was wondering if it would be possible to tag issues in the queue as <a href="http://drupal.org/project/issues/search/?issue_tags=D7 stable release blocker" rel="nofollow">D7 stable release blocker</a> if they're something that needs to be fixed before that happens, so we could try and get some helping hands on them? </p>Tue, 13 Sep 2011 03:23:03 +0000webchickhttps://www.drupal.org/node/1277262Migrating image fields ended up swapping files to userpichttps://www.drupal.org/node/1558192
<p>I was trying to upgrade around 5k nodes with image field, all went supposedly good (no errors). But the operation ended up having a bunch of user pictures replaced with files from those node fields. Puzzled.</p>
<p>Less busy content type (a few dozen nodes) was upgraded just perfect.</p>
<p>Any pointers where to look to try to track/fix this behavior?</p>Wed, 02 May 2012 18:31:53 +0000betarobothttps://www.drupal.org/node/1558192Corrupted file URI after filefield migrationhttps://www.drupal.org/node/1732944
<p>Because of <code class="language-php">str_replace()</code> usage in <code class="language-php">content_migrate_filefield_data_record_alter()</code> all occurrences of file directory path will be removed from the file path and not the only one at the beginning.</p>
<p>For example, when file directory path is just "<code class="language-php">files</code>" and file path is "<code class="language-php">files/profiles/my-files/img1.png</code>" the URI becomes "<code class="language-php">public://pro/my-/img1.png</code>", which is really wrong and we expect "<code class="language-php">public://profiles/my-files/img1.png</code>".</p>
<p>Patch follows.</p>Wed, 15 Aug 2012 16:46:52 +0000Dmitriy.trthttps://www.drupal.org/node/1732944Spelling errors in D6https://www.drupal.org/node/2555975
<p>few spelling mistakes in module</p>Sun, 23 Aug 2015 06:39:37 +0000rrfegadehttps://www.drupal.org/node/2555975Text Widgets Incorrectly Use &quot;Many to One&quot; Argument Handlerhttps://www.drupal.org/node/359661
<p>I was building up a View recently and noticed that the very helpful "Convert to lower" options were gone when dealing with CCK Text select lists (they still work fine for textfields strangely). When poking through the Views documentation I found this helpful comment in the Views docs (in views_handler_argument_many_to_onc.inc):</p>
<pre class="codeblock"><code class="language-php"> * - numeric: If true, the field will be considered numeric. Probably should
* always be set TRUE as views_handler_argument_string has many to one
* capabilities.
</code></pre><p>
So basically we've been using the wrong handler for text. Since we've switched to using the many_to_one handler we've lost all the nice options that the text handler gives us, yet it turns out the text handler had many to one support built into it directly!</p>
<p>Take a look at the attached screenshots of the many-to-one, text-only, and text-many-to-one-enabled. Seems like this enhancement would be a winner for everyone.</p>Fri, 16 Jan 2009 08:24:30 +0000quicksketchhttps://www.drupal.org/node/359661