Can't create anymore mini panels

Can you provide more details as to what exactly you're doing? I have 6 minipanels and they all work fine, even with context or content added.

Well, if it helps, this indicates that the layout is somehow disappearing. How or why, I'm not sure.

OK, I watched it, and I've done the same things, and I still can't replicate it :/

I've been fighting this same problem. I *believe* that I've found the problem/solution. In my case, if I create a new mini panel and don't change the context page, but go to the content tab, I am unable to modify the content. I MUST save the blank context page first. Then, I can change the content.

See if this helps you.

Thanks constantinus! That worked for me, was having the same problem.

ALTER TABLE `panels_mini` ADD `category` VARCHAR( 64 ) NULL AFTER `name`

The problem has returned, and now I have the category column there. Something is wrong with mini panels I think.

Rows are being added to the table that have a pid of 0 and no value for category (not even NULL) which seems to be breaking some things in the UI.

I am also experiencing this problem. I have 6 mini-panels. Looking at the DB they have pid's of 1,2,3,4,6,0 (0 is the newest one, added several months ago). Now I can make no more. I can (as previously described) edit older ones, but the new one that I try to add will not appear in the DB at all. What kind of additional information can I provide to help? I've attached a screenshot of my panels_mini db:

Adding version update and also noting that exporting a working panel and trying to re-import it with a different name (20 characters long) also fails at the step where you would see the content. The import shows (in the column to the right of the step where names are provided) that there are multiple panes with content in them but after hitting "save and proceed" twice I come up to the empty "edit-content" step. Note that the system reports "Your new mini panel New Panel Name has been saved." after the first "save and proceed" and says "Your changes have been saved." after the 2nd "save and proceed". Even if I click "save" here, nothing is added to the database.

Ok, that id of 0 is very suspect. That suspects that the auto increment counter has somehow reset, which...I have no idea how that could happen.

It is entirely possible that after 5 attempts this could fix itself.

Can you paste to me the results of this from your mysql command line:

DESCRIBE panels_mini;

(Be sure to put it in <code> tags so it doesn't lose formatting)

Thanks, Merlin for looking at this... Here's the result of the describe command:

+------------------+--------------+------+-----+---------+-------+
| Field            | Type         | Null | Key | Default | Extra |
+------------------+--------------+------+-----+---------+-------+
| pid              | int(10)      | NO   | PRI | 0       |       | 
| name             | varchar(255) | YES  | UNI | NULL    |       | 
| category         | varchar(64)  | YES  |     | NULL    |       | 
| did              | int(10)      | YES  |     | NULL    |       | 
| title            | varchar(128) | YES  |     | NULL    |       | 
| contexts         | longtext     | YES  |     | NULL    |       | 
| requiredcontexts | longtext     | YES  |     | NULL    |       | 
| relationships    | longtext     | YES  |     | NULL    |       | 
+------------------+--------------+------+-----+---------+-------+
8 rows in set (0.05 sec)

Here's another interesting thing that's happening for me. If I go to an existing mini panel and edit the "Mini panel name", I can hit save but the next screen displayed will have those same fields empty. If I then click on "Content", I'll get a similar situation to trying to make a new mini-panel, empty edit-content screen. (although %252F does not appear in the URL in this case).

However, if, instead of clicking on Content immediately, I go back to the admin/build/panel-mini page first, I'll see my newly edited mini panel complete with new panel name and then click on Edit link > Content tab and the layout grid will be there.

Also, I did just try creating a new mini-panel about 8 times just to test your idea about it fixing itself. No luck. :-/

Hmmmmm. The pid column of that table seems to have lost its auto increment setting. That's really odd. I can't imagine why that would've happened.

It does seem as though the update never did this. I'll work up an update patch. I don't know the SQL required to convert a field to auto increment off the top of my head, but if you want to google for that it might provide a workaround.

I googled a bit and found the following description at this website to change a field to auto_increment:

Source: http://www.plus2net.com/sql_tutorial/sql_alter_table.php

Explanation:
Adding / Altering a numeric field to auto increment field

[...] We can convert one existing numeric field to an auto increment field in two steps. First making the filed unique and then altering the field to add auto increment property to it. We will start with making it unique

Declaring an numeric filed to be unique

$q="ALTER TABLE `message_table` ADD UNIQUE (`msg_id`)";

Here in the message_table we already have one numeric filed msg_id and we have made it to UNIQUE field so no duplicate data is allowed, if any duplicate data is there then we will receive error message.

Now let us change it to add auto increment property to it.

$q="ALTER TABLE `message_table` CHANGE `msg_id` `msg_id` INT( 4 ) NOT NULL AUTO_INCREMENT ";

Now our msg_id field became auto increment.

-----

So, if I apply this to my my panels_mini table, I'd want to do it for 'pid' instead of 'msg_id' and what does the 4 in the () after INT mean? Would I need to change that to INT (10) to match my existing table?

Thanks.

I can confirm this issue as described. I would also note that the sidebar in garland disappears as well as described. Furthermore, when adding contexts, I receive a server input error.

I am happy to post back SQL queries if it would help resolve this issue.

Thanks!

Not sure if it's protocol or not to change the status of an issue from postponed (maintainer needs more info) to active, but I thought I'd (respectfully) push my luck.

I'm willing and eager to provide any more information, but I'm not sure what could help.
If not Merlin, could anyone else possibly answer my question at the end of #19?

corona, I think it would be helpful if you did the same thing that I did in #16.... (at Merlin's request in #15) to see if the same thing happened to the PID column of your table.

Thank you.

The easiest way to answer the questions, I think, is to show you what the table *should* look like:

+------------------+--------------+------+-----+---------+----------------+
| Field            | Type         | Null | Key | Default | Extra          |
+------------------+--------------+------+-----+---------+----------------+
| pid              | int(11)      | NO   | PRI | NULL    | auto_increment |
| name             | varchar(255) | YES  | UNI | NULL    |                |
| category         | varchar(64)  | YES  |     | NULL    |                |
| did              | int(11)      | YES  |     | NULL    |                |
| title            | varchar(128) | YES  |     | NULL    |                |
| requiredcontexts | longtext     | YES  |     | NULL    |                |
| contexts         | longtext     | YES  |     | NULL    |                |
| relationships    | longtext     | YES  |     | NULL    |                |
+------------------+--------------+------+-----+---------+----------------+

If you make your table match that, then everything should be ok. I'm not sure the difference between int(10) and int(11) particularly mater.

re #21 Its perfectly fine to change the status as long as you feel like you have good reasons other than the issue is important to you personally ;-)

#19 sounds like its on the wrong track -- i suspect you have an upgrade problem (i've never seen the issue you described and use min panels all the time).

Perhaps the most valuable thing you could do for us: attempt to reproduced this bug on a fresh install with a fresh version of panels and mini panels. If the bug is still there, then please document the steps for reproducing it. Otherwise at least we know where to start sniffing.

dccircuit, I ran:

ALTER TABLE `panels_mini` CHANGE `pid` `pid` INT( 10 ) NOT NULL AUTO_INCREMENT;

and so far this seems to have fixed the issue.

I am also having a similar problem with mini-panels.

I installed the module and it seemed to work well. After I created 4-5 mini-panels it stopped working. In other words, I clicked on
administer/site building/mini-panels

I created a 2 column panel. context:node

I attempted to import an image. Before importing, I noticed that the word "link" was still present but the field to input the link had disappeared.

I attempted to load an image. I was able to use the dialog box to find the image and start an upload, that is where mini-panels failed. It sat for about 10 minutes with a progress indicator spinning to show that the upload was in progress. The image appeared in the background as though the upload was active. Mini-panels would not, however, complete the upload operation. Closing the window and clicking save causes the image to disappear.

I've tried everything to fix the problem; clearing cache, checking the PID to make sure it is still set to auto-increment, etc. It looks like the problem has something to do with a call to update the database.

It looked like a corrupted inc file so I uninstalled min-panels and reinstalled it. Still nothing. The last time this happened I had to completely uninstall Drupal and start from scratch to get mini-panels to work again. I don't want to go there again, if there are any willing souls here please help!

JA

Mini panels do not handle image uploading by themselves, so I would look into the module that is handling that.

merlin
Thanks -- from what I can remember, mini-panels seemed to quit in relation to CCK being installed and activated.
Conflict?

It's certainly possible that there is a connection.

The UI was completely changed to different code in 3.7 so this issue is probably not relevant anymore.

Related to this #931648: Notice: Undefined index: description in ctools/includes/content.inc on line 72
Solution was to add in a column called title to the panels_mini table. This is a mirror of the admin_title field.

I'm not sure if this is the same as the rest of the issue as it got rather twisty up there but I'm having the exact same problem as #31. I have an admin_title field and not a title field and my minipanel went *poof* when I saved it because of that.

I have no idea what led to my table being different. I've updated Panels many, many times. Somewhere in there some change must have gotten lost. Because this causes you to lose all your work and you don't even know why unless you check the logs, could there possibly be a check added to make sure that field exists?

Michelle

Well, the field is added by function panels_mini_update_6303() {

I don't really think adding a check for a field that has no reason not to be there is a good idea.

Sorry, the admin_title field was added.

The title field was removed. There should not be a title field.

This issue is really confused.

There is no explanation for why adding a title field even helps.

adding the title field to the DB was a lucky guess after looking at what the code was trying to do
#887546: Notice: Undefined index: title in panels_common_settings() - here you stated that this is an issue with ctools & was fixed.

3.8 doesn't use the field anymore. I have no idea what happened in my case. I suspect something got messed up on my site due to all the problems I had with upgrading. Possibly I had a version that made the data change and then went backwards when the upgrade failed. At any rate, this is a non issue for me, now.

Michelle

Okay, marking fixed then. If someone else continues to have this problem we can re-open it.

Using 6.x-3.9. I hadn't used minipanels much so never noticed the problem. But after the sixth minipanel, new ones aren't being saved. There's a lot going on in this thread so I am seeking clarification.

I upgraded to the latest 6.x-3.x-dev version but this didn't fix the problem.

I think I found the solution in this thread, but I want to make sure. The "alter table" statement in #24 worked in my test site. But I want to be careful before doing this for my public site. Is this the solution? Or is there an upgrade that maybe didn't take in the install doc for panels_mini?

Thanks lots.

mrweaver

Interesting. If #24 fixes it, there was something wrong with the database, possibly update.php did not run or work properly.

I had run update.php.

Should I manually select one of the updates for panels_mini and/or panels?

Thanks

I took my test site back to 6.3.9 and manually selected updates for panels and mini panels. Looking at those updates, I don't see one that affects the autoincrement on the pid. Would this have been from as far back as D5?

FYI: I looked at #22, saw that my table's pid was not auto-increment, tried to edit the table in phpmyadmin, but got a weird error.

So I exported my current panels + mini panels, and removed the modules, uninstalling them (6.x-3.9), and re-installing latest (6.x.3-10). Looking in the DB, after reinstall and running update I see that the tables are now correct for mini panels.

I can now create new mini panels and they appear as expected.