This issue is for the tracking of the porting of the 5.2.x branch to Drupal 6, which I am currently working on.

CommentFileSizeAuthor
#70 Panels Port.patch197.1 KBPancho
#38 panels.6.1.patch55.32 KBPancho
#9 panels6.1.patch55.89 KBNick Lewis
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Roxpace’s picture

How far has the upgrade came and if you need help, with what do you need help with ?

cwgordon7’s picture

I need help with porting Javascript. I do not speak js.

Roxpace’s picture

I can manage that too, what rest is updated ?

wayland76’s picture

subscribe

zilla’s picture

happy to test an alpha if there is a rolled up version in the cvs or project page - i'm very eager to see how panels2 works with d6.1 - if you release an alpha or beta over the coming weeks, i'm more than happy to test it out and report back on any issues, glitches, etc...

encho’s picture

Subscribing to the issue.

designerbrent’s picture

subscribing

Nick Lewis’s picture

Talked to Merlin, taking a first pass at porting panels. Focusing mostly on low hanging d6 api changes (forms, menus, and theme functions). Will submit patch.

Nick Lewis’s picture

Status: Active » Needs work
FileSize
55.89 KB

This patch is maybe 10% of the work needed to port panels to d6. I may not have time to work on this tomorrow through the weekend. I'm only providing this patch for a developer who might like to pick it up where I left off while I'm MIA.

The panels module, and panels_page module can at least be enabled and work well enough to port without flying blind. I also ported the schema, but the autoport needs to be reviewed, and cleaned up a bit. Panel pages appear to save correctly. However, there's a big nasty menu issue in panels_page that'll need some major reworking. Working out that menu problem appears to be the next major task.

Major tasks identified so far:
1. Panels sends all menu items through a wrapper function that emulates core 6.x menu behaviors. We could probably get away with not touching it, but its certainly code debt from pre 6.x.
2. panels_page_menu() -- This is the biggest scariest thing I've found so far. See the code below:
(panels_page.module 120 -- within hook_menu)

// Get all panels and, if enabled, create menu items.
  foreach ($panels as $panel_page) {
    if (empty($panel_page->disabled)) {
      // Only create menu items based on the path if it's not a variable path.
      if (strpos($panel_page->path, '%') === FALSE) {
        _panels_page_create_menu_item($items, $panel_page, $panel_page->path, array($panel_page->name, FALSE));
        // DEBUG: Above is now creating only the basic menu item, not the admin items.
      }
      panels_page_admin_menu_items($items, 'admin/panels/panel-page/' . $panel_page->name, $panel_page);
    }
  }
  // Look for panels with variable arguments.
  // Build an array of $urls because 'real' URLs will take precedence over
  // argument filled URLs
  $urls = array();
  foreach ($panels as $panel_page) {
    $url[$panel_page->path] = TRUE;
  }

  $plugins_loaded = FALSE;
  foreach ($panels as $panel_page) {
    if (strpos($panel_page->path, '%') !== FALSE) {
      $path = explode('/', $panel_page->path);
      $match = TRUE;
      foreach ($path as $id => $chunk) {
        if ($chunk != '%' && $chunk != arg($id)) {
          $match = FALSE;
          break;
        }
      }
      // It's a MATCH! Construct the URL
      if ($match) {
        $args = array($panel_page, FALSE);
        reset($panel_page->arguments);
        foreach ($path as $id => $chunk) {
          if ($chunk != '%') {
            continue;
          }
          // For arguments that are embedded in the URL, we require the
          // argument handler to return a context, if there is an argument handler.
          $argument = current($panel_page->arguments);
          if ($argument) {
            // Try to avoid loading the plugins code unless necessary.
            if (!$plugins_loaded) {
              panels_load_include('plugins');
              $plugins_loaded = TRUE;
            }
            $context = panels_argument_get_context($argument, arg($id));
            if (!$context) {
              break;
            }
            $panel_page->context[panels_argument_context_id($argument)] = $context;
          }
          $path[$id] = arg($id);
          $args[] = arg($id);
          next($panel_page->arguments);
        }
        _panels_page_create_menu_item($items, $panel_page, implode('/', $path), $args);
        // DEBUG: Above is now creating only the basic menu item, not the admin items.
      }
    }
  }

This code really gets to the heart of what was wrong with pre-d6 menu's. From my view, these operations will need to be rewritten to make use of wildcards, and d6's menu_links table. Unfortunately that means that a lot of code is going to have to float from here to form submit functions, menu callbacks, and other places far and away from this original code. In addition, it looks like loading functions will have to change to support the wildcards.

So I take it back, this patch is 5% of the work that needs to be done.

cwgordon7’s picture

What are you doing??? This is assigned to me, and I am working on it. You are duplicating much of the work I have already done :P.

Nick Lewis’s picture

Status: Needs work » Active

Doh - Merlinofchaos had encouraged me to help out on this -- figured you were working on other things. Need this module ASAP for some work I'm doing at my company. Want to split out some work to me? Happy to be of service. If you can give me a patch of that work, I can help you out with javascript. I speak javascript. :-p

Gonna put this back to active since your patch should be the start point.

merlinofchaos’s picture

Sorry, cwgordon07; the issue is almost a month old, I forgot you were initially working on it, and I get asked almost every day about Panels 2 for D6; so I'm encouraging anyone with an interest to collaborate here, since I'm pretty focused on Views 2. Keep rolling patches forward.

jorisx’s picture

really cool you guys are porting panels to 6 :-)

keep up the good work!
and keep me posted[subscribing ;-)]

zilla’s picture

subscribing

allartk’s picture

subscribing...

kyle_mathews’s picture

subscribing

merlinofchaos’s picture

Status: Active » Needs work

This still contains a patch (makes it easier for me to find it, too)

t.karkoulis’s picture

subscribing

MichaelK-1’s picture

subscribe

DaveNotik’s picture

Subscribing.

(My, we need a "Subscribe" toggle on drupal.org, eh? It shouldn't require you to comment to subscribe.)

beerlao’s picture

Subscribing.

agentrickard’s picture

@cwgordon

Status?

I have some spare personal time coming up and need to start thinking about Panels/MySite integration in D6. So if you have an active patch, I'll be happy to test and start writing some code.

jhuckabee’s picture

subscribe

kbahey’s picture

Subscribe ...

Patch by Nick Lewis no longer applies. Many failures in it.

Wim Leers’s picture

Subscribing.

Note that due to the simplicity in code (i.e. lack of using any of Drupal core's hooks) of Panels style plugins, the D5 versions will work just fine in D6.

amitaibu’s picture

Subscribing

vegeneric’s picture

subscribe

rbns’s picture

Subscribing.

mrgoltra’s picture

subscribing.

bonobo’s picture

Subscribing

soethiha’s picture

tuning in...

Vigile’s picture

#25
Wim Leers - April 12, 2008 - 20:34

Subscribing.

Note that due to the simplicity in code (i.e. lack of using any of Drupal core's hooks) of Panels style plugins, the D5 versions will work just fine in D6.

What do you mean here? The main Panels 2 code should on D6? Or just the Panels add-ons from the contribs?

Oh, and also subscribing - desperately wanting this for current project.

Vigile’s picture

Sorry for double!

Wim Leers’s picture

@Vigile: Panels plugins from contrib, at least the style plugins, will continue working. Panels 2 itself obviously won't work in D6 yet.

Vigile’s picture

Thanks! Eagerly awaiting some updates - just starting with Drupal so development isn't an option yet but I can definitely help with testing!

locdao’s picture

subscribing

Pancho’s picture

Assigned: cwgordon7 » Unassigned
Priority: Normal » Critical

I changed the status description on Contributed module status, as it raised expectations that the current patch cannot fulfill.

Hope I'm not too bold raising priority and unassigning cwgordon7 for now. I want others to feel invited to help out. Feel free to reassign in case you're stil working on this.

I'll try to chip in some more 2% of the porting work, but can't promise to succeed. While other important modules are still alpha or beta, from all the modules I need for my latest project, this is the only module that doesn't work at all and keeps me from using D6.

Pancho’s picture

FileSize
55.32 KB

Okay, I added another one percent or so of the porting work. In the 'edit panel page' administrative section, the local tasks now work more or less correctly. Still lots of errors and no use of wildcards, but now we can at least get a picture of what else needs to be fixed.

For now I will stick to rewriting the menu functions. I decided to post every little progress, because this makes it easier for others to chip in fixes in other areas. Everybody: please help!!!

bitsantos’s picture

(subscribe)

I've been asked to make something like this for work but I think it'd be better if I just helped with this. What in particular has been finished and what else needs to be done?

bitsantos’s picture

Perhaps a to-do list would be nice. Or even just a function checklist. I'd really like to start helping but I have no idea where to start. :-)

Pancho’s picture

Hey bitsantos! Great to hear you want to help out porting this module. I found out that it has a pretty complex architechture, so you'll need some time to understand the inner workings. But no panels in D6 is definitely a big show-stopper, so thanks for any kind of help!!!

Right now, I'm working mostly on the panels_page sub-module, so if you would start with panels_node, we shouldn't do the same things twice. I'm gonna post a new patch asap, after the tasks I'm working at have been completed!
To-do list? Might not be too easy, as the tasks are pretty meshing up, and often you only see the next problem once you fixed the current one - but let's see then...

agentrickard’s picture

Personally, here's what I'd like to see, in order:

1) Separate the core Panels API into a module and port it to D6. Do not include any menu functions or higher-order functionality.

2) Port the existing Panels includes (layouts and such) to D6.

3) Port the features of 5.x.2 to a new Panels Admin module.

I have slightly selfish reasons for this, but abstracting the API -- much in the way that Views and View UI are now -- is, IMO, essential to future development.

bonobo’s picture

RE:

1) Separate the core Panels API into a module and port it to D6. Do not include any menu functions or higher-order functionality.

2) Port the existing Panels includes (layouts and such) to D6.

3) Port the features of 5.x.2 to a new Panels Admin module.

+1

merlinofchaos’s picture

The API is already abstracted. I'm not sure what this Panels Admin module you mention would actually do, but I have a feeling that it's already abstracted in a manner that you want.

sdboyer’s picture

Priority: Critical » Normal

OK, so I have some emerging concerns about some of the elements in recent comments. I certainly understand that Panels is a really important site development element, but it is a very a complex module, and IMO, if the port to 6.x tries to accomplish any changes to the module itself, it drastically increases the likelihood of us having a Panels6 port that nobody is happy with. Please believe me when I say that we'd have to write the big-brother sequel to The Road to Drupal Hell if that happens.

So in part, this is Ken's comment in 42 - I'm not really sure how we'd abstract the Panels API any more. The menu functions that are in the main module are (almost exclusively) the ajax passthroughs that are necessary for most panels editing operations; the main editing entry point functions (panels_edit_display(), panels_edit_layout(), panels_edit_layout_settings()), are there, along with some basic display- and pane-loading, saving, and exporting functionality. The remainder of the API is essentially what you see in the /includes directory. All the other stuff - panels_node, panels_pages, panels_views, the legacy stuff, panels_mini...it all HAS been abstracted out into separate modules, themselves nothing more than heavy-duty implementations of the core Panels API.

Moreover, there still is more to be done on Panels2.x itself. Even if it works quite well, and it does, generally speaking, there's a reason it's not even RC yet. My general planning has one, possibly two more beta releases, then we can get into RC, but I've very deliberately decided not to begin moving Panels to 6 until we're done developing it for 5.

Now, that doesn't mean I think people shouldn't work on the port to 6.x. It needs to be done, and given the extent to which Panels is a world unto itself, there's a lot in it that DOESN'T need changing in the port. However, what it does mean is that people should do that work with the dual understanding that, a) because the 2.x API is still subject to change, you might end up spending hours/days working on something that ultimately disappears, and b) that I can't promise to give full attention to the questions/patches being raised here until I've gotten to the point where I'm also working on the 6 port, as my mind is (and needs to stay) focused on finishing 5--2.

agentrickard’s picture

I believe I have just revealed my ignorance of the inner workings of Panels.

I'll be off work next week and have a chance to dive in to the code.

lourenzo’s picture

subscribing

bejam’s picture

subscribing

Pancho’s picture

No doubt, it is not directly a good idea to port a beta and then port all further changes again and again. The point is: Panels 2 beta3 is good enough for most needs, and people are happy to have exactly this version of panels ported to D6.

Suppose you continue developping Panels 2 for D5 and you need two more months to present a final for D5. Then you start porting to D6, need to change the architecture again, need to test and improve and make it actually work in D6. It's gonna be July or August by then and CCK, Views and all the other stuff are usable for quite a long time. I don't think people will be waiting so long, they will try to avoid using panels or build custom solutions or publish some kind of "Panels Lite for D6" (see the comment by bitsantos).

I don't think we want this and I therefore propose to start porting now, and as soon as the port works we all should move our developing focus on pushing the D6 version to a final, only porting pack the changes to D5. Then we might have a working D6 beta in May and people can start adopting it for their projects.

Michelle’s picture

I disagree. There are a _lot_ of people using this on D5 who shouldn't just get put on hold. No one is using it on D6, yet. Let's get the D5 version at least to a stable release ASAP. If someone wants to work on the D6 port in parallel, that's fine, but I don't want to see D5 just stop at beta 3 and sit there until the D6 port is done and backported.

Michelle

merlinofchaos’s picture

As long as the people porting to D6 are willing to keep the patch up to date and deal with merge issues, there's no problem. But I, personally, am not even going to look at the Panels to D6 stuff until Views 2 is stable and I can turn my attention away from it.

bitsantos’s picture

Sorry to have raised any hopes, guys, but for our current project at work we've decided to go in a different direction so I won't be able to help with the porting. I'll try to pick it up in my free time (the little that I'll be getting). Good luck. :-)

ogi’s picture

subscribe

seanr’s picture

re: http://drupal.org/comment/reply/223994/813663#comment-813663

That's specious reasoning IMO. No one's using it on D6 because it's not yet available. If it were, I guarantee you I'd be using it, and probably others as well. The D5 one is fairly stable (I have no problems with it). I'd really like to start building new sites in D6 but can't because I rely on Panels pretty heavily and I imagine there are a great many people in a similar position (lack of ported modules preventing them from upgrading).

BTW, just (re)ported one of my own module, Forward, to D6 today. ;-)

Michelle’s picture

"No one's using it on D6 because it's not yet available"

Obviously. That was my point. Since it's not available, I can guarantee no one is using it on D6. But there are plenty of people using it on D5 that could use a completed version. I'd love to have a D6 version as well. I'd love to have views and CCK and 100 other modules available for D6. But there is only so much dev time to go around. My feeling (for whatever it's worth since I'm not the one coding it) is that it's better to get 5 finished and then port the finished product to 6 than just abandon everyone on 5 for however long it takes to port it to 6, then finish it, then backport it.

Michelle

PGiro’s picture

subscribe

Pancho’s picture

Assigned: Unassigned » Pancho

I'm already working on a port, let's say 50% done. Maybe I'll need some help here and there with AJAX, but the rest should be pretty okay by next week.
Can't promise anything, but I want this so much that I can't help working on it 24h. Weekend's off though, so you'll hear from me next week.

Enjoy the great weather (at least here...)! Pancho

flickerfly’s picture

sub - Pancho, could you post a patch of what you have so that others could look at it and maybe help take it to 60% over the weekend?

dami’s picture

subscribe

ardee-1’s picture

Subscribing...

hass’s picture

subscribe

wayland76’s picture

Title: Port of 2.x branch to d6 » Port of Panels 2.x branch to d6
Passionate_Lass’s picture

subscribing

lionstone’s picture

Let me know if you need any jQuery help .

Subscribing...

skilskilskil’s picture

subscribing

danmurf’s picture

Subscribing...

GreenSkunk’s picture

Subscribing

kenjiru’s picture

I'll check if there is anything I can do...

Subscribing...

khanz’s picture

Subscribing

Pancho’s picture

Assigned: Pancho » Unassigned
FileSize
197.1 KB

I'm posting now what I have, because I'll not be able to continue with the port until next week (which is why I unassign for now).
Many things had to be changed, unfortunately I don't have the time now to document everything, but I'll follow up with that.
I started with porting the general Panels module and the Panels_page submodule. Some things do work now, others don't. I guess we should finish porting these two modules and then turn to all the other submodules, which shouldn't be too much work then.
Are 50% of the work done? I thought it were, but then there were some more tricky little problems, so I guess we're at 30-40%.

dami’s picture

Looks like nobody has enough time or incentives to work on it by him/her own.
Is it a good idea to piecemeal it? It needs some collaboration and documentation on open items.
Can we commit whatever we have for now to 6.x-dev, and work from there?

merlinofchaos’s picture

No; there's too much going on, it'll be much easier to cvs up and keep a rolling patch than it will be to commit and and then try to develop in two branches.

CompShack’s picture

I'm getting ready to upgrade to D6 and have to make a decision to whether upgrade without Panels cause D6 version is not out yet :(

Pancho’s picture

I'm back now, and though my time will be limited this week, I'll try to document the changes made and isolate open tasks. I also need to clean up the patch.

Regarding dami's suggestions: Would it be a bad idea to temporarily create a separate project "Panels D6 Port" (just as a "Drupal project", not as a "Module"), so we are able to use CVS and the project features? For every 5.x-2.0 beta, we would commit the original code as a new branch point and then we would roll over the patch. Obviously, we'd need to keep the port up to date until Panels 5.x-2.0 finally releases, then you could commit the final patch back to the Panels project and we'd close the temporary project...
Sounds complicated, but in the daily work, I think it would be easier and more inviting to others than just a rolling patch.

The general guidelines for a patch should IMHO be:
- Optimize the code using new possibilities of Drupal 6 and jQuery 1.1.1
- Minimize API changes
- No feature or string changes
- Port back to the 5.x-branch whatever applies there as well.

wayland76’s picture

@Pancho: no, I think that's what CVS branches are for :). I'm not even sure the optimisation is a good idea at this point :), but since I'm not the one coding it, I don't mind :).

merlinofchaos’s picture

A separate project would be confusing and, as a project administrator, I'd very seriously consider unpublishing it.

I understand people are excited about Drupal 6 work, and I am too, but let's not put the cart before the horse.

And PLEASE do not do any optimizations. There's already some questionable changes in the patch as it is that are not strictly part of a port.

wayland76’s picture

Just to make it clear then -- I think what merlinofchaos is really saying is that, in this issue, the patch should only be the things absolutely essential to a 6.x port; other things should be associated with a separate issue (merlin, could you confirm this?). The beauty of doing things this way is that it means that we get a 6.x port faster, and then once we have the port, everyone can get hacking on it. It also means fewer bugs in 6.x-2.0 -- optimisations belong in 6.x 2.1, I think. Of course, the quick hacking mentioned above depends on branching CVS when we have the 6.x port, which may not be what happens.

I note 5.x-2.x is in beta. Does that mean that it's moderately stable, and mostly looking at bugfixes?

sdboyer’s picture

@wayland76:

Yes, Panels2 is pretty stable, but it would probably be more accurate to say that it being in beta means that the API won't be changed - not that there aren't other things to be added. As it sees more and more use, we continue to come across very legitimate use cases that, it's our feeling, a full-blown Panels release simply isn't complete without. One such example of this is the ability to hide or show a pane through the use of a simple toggle button on the content editing form - something that will be available for beta4, as a number of use cases that have been presented demonstrating how the absence of that feature necessitates rather painful workarounds. To be concrete about it, I'm keeping a list of items like that need to be added before we'll go RC; once we hit RC, then as far as I'm concerned, it's straight bug fixes up until release. I am planning on posting at least portions of that list up into the queue as tasks so that folks can more easily keep track of the progress.

Let me just say that I really am as excited about a 6.x port as anyone, but I'm also painfully aware of the number of issues that remain with panels. Though the interest and excitement in this thread thrills me, it's just one facet of what's in the queue. So let me second merlin's sentiments by saying - PLEASE limit the contents of the patch strictly to what needs to be done for the port to 6. Not only is it right there in the issue's subject, but it's the same standard I'll be holding myself to when working on the port. Nothing, least of all me, is stopping anyone from opening issues with non-port-related patches.

wayland76’s picture

@sdboyer: The "Version" field for the issue can't be set to 6.x until there's at least a 6.x dev version. That's one of the things I was thinking about here :).

@Pancho: Thanks for all your great work, but maybe one thing at a time. Can this be split into (at least) two patches/issues?

Pancho’s picture

Thanks for all your comments!

I understand that splitting out the port to a separate project creates problems. This was just an idea, and if it is considered a bad idea, I certainly don't want to force it.

To accommodate Earl's headaches with changes that might have gone too far, I'll probably start from the scratch, changing only the minimum needed for Panels 2 to be usable with D6. This may include duplication of D6 core functionality, loading more code than necessary etc. and undoing some of the changes that were already rolled into Nicks patch in #9. Instead I'll isolate a number of follow up tasks and create issues for them.

wayland76’s picture

Just to clarify, I'm no-one official here, I just try to make sure we're all communicating properly :).

greggles’s picture

subscribing (sorry for the bugspam).

rmiddle’s picture

Subscribe

sdboyer’s picture

@Pancho in #80:

Great, we definitely appreciate your taking this more targeted approach. It'll make for less headaches for everyone in the long run, I suspect.

Pancho’s picture

sdboyer: Cool, I think this way it's gonna work out well, though it might take some more weeks. At a later stage I'll probably need some input by MenuAPI resp. JS/AJAX experts.
What I did is restarting the port from the scratch in my sandbox. I'm not yet where I was before, but documented every step.
Right now I'm creating separate issues for all those little changes I had rolled into my initial port patch, which also apply to the D5 version of Panels2. Would be cool if you found some time to take a look at those issues, even though they are non-critical...
From time to time I'll also roll in your commits in the D5 branch to keep the development parallel. This is going to be quite some work, but I'm still sure it's worth it!

sdboyer’s picture

Cool beans - again, much appreciated. Yep, I've been noticing the other issues you've posted - keep em coming! I'll commit whatever & whenever I can. I also just posted what are currently the biggest chunks on my todo list before we go RC with panels2; you might want to familiarize yourself with those so that you know where changes are more likely to occur. They were all posted in the wee hours this morning (May 9th) as tasks.

Yep, there's quite a bit to do here, but someone's gotta do it. Now, what's REALLY gonna be a lot of work is panels3...which is likely to involve a pretty much full-blown rewrite into OO, to say nothing of the UI changes and feature additions :) But one step at a time, we're not even thinking about that until panels2 is released and the D6 upgrade is complete.

merlinofchaos’s picture

I'm excited to see those issues (and you won't hear that from me very often =) -- many of them are good improvements!

alanburke’s picture

subscribe

Rob T’s picture

All the work done here is much appreciated. I was looking through Pancho's sandbox, reading the TODO, Known Issues, etc, and I am curious...

What is the functional status of Pancho's work? Is basic (v1) Panels functionality working well with the young code? If so, and if one is not looking for all the flair and functionality of Panels2, could we use the Pancho Files in their current state for some basic panels... and would the transition to the to-be-released "official" version of D6 Panels2 be not-so-painful?

I realize I'm probably way too eager to get some basic panels up on the D6 site I'm working on. But if some of the traditional functionality is working OK, and it won't be too much of a hassle when going to an official release, then I am really tempted to give it a shot.

mozaicbox’s picture

subscribe

bensnyder’s picture

subscribing

mentat.fr’s picture

Subscribe

reload’s picture

subscribe

bensnyder’s picture

Is it possible to release a Panles 6.x-2.x-dev yet??? I'm eager as hell to test it and help get it to a beta release..!

merlinofchaos’s picture

peglegax: When it's possible it will be done. Please be patient; you're not helping.

Pancho’s picture

pegleglax: No, at the moment it is not possible, and it will unfortunately take some more weeks. :(
Panels2 for D5 is that much a moving target, that any porting work is double work ATM. If you'd like to accelerate things a bit, Earl and Sam would be happy about your help in the Panels issue queue. The earlier a Release Candidate for D5 is published, the earlier porting work can resume...

hankpalan.com’s picture

Subscribing...

cammangels’s picture

subscribing

cpelham’s picture

Subscribing...

enthusaroo’s picture

subscribing...

davedelong’s picture

subscribing

YesCT’s picture

subscribing

webchick’s picture

...

Frieder’s picture

subscribing,

looking forward for a Panels 2.x RC, so we can start the real porting work for D6. I need this for a project and i don't want to downgrade to D5.

bensnyder’s picture

I understand how to write modules although I've never ported one. I'd be glad to take on as much of the work as I can to port Panels to D6...

Does a project administrator need to assign work? If so, count me in. Thanks guys for keeping the ball rolling~!

emptyvoid’s picture

Subscribing

chadd’s picture

subscribe

RoboPhred’s picture

suscribe

wayland76’s picture

@peglegax: No, just assign the thing to yourself if you're going to give it a good solid shot. The proper procedure includes:
1. Use the latest CVS version of Panels2 as your starting point
2. Install the Coder module, and do a code review, and include the tickbox about porting from 5.x to 6.x. This won't tell you everything, but it'll get you well started.
3. Go through the list of things on the 5.x to 6.x conversion page, and see if you can find any of them in panels, and convert that stuff
4. If there's any Views-related stuff in Panels2, port this to Views2 while you're at it

You may also want to use the Devel module. Post patches on this thread that are diffs from the lastest CVS of Panels-5.x-2.x sources. This will be a moving target, so you'll need to update your patches from time to time.

HTH,

perhenrik’s picture

suscribe

mbbid5r’s picture

Subscribing

faunapolis’s picture

subscribing. Is there a way of subscribing without disturbing any thread? Sorry about the interruption, but very interested in this thread :)

Guillaume Beaulieu’s picture

If this helps in any way, I worked on a port of panels 1.2 to drupal 6 since I thought at first there were no work undertaken to port panels2 to drupal6 for now. I'll quit my work on that right now, and start to help out. Here's what I've done...

hass’s picture

@Guillaume Beaulieu: Seems like you missed my port #206962: Port panels 5.x-1.x to D6

Owen Barton’s picture

...

BenK’s picture

subscribing, too...

carlmcdade’s picture

subscribing

cedrix’s picture

subscribe

Etanol’s picture

Well.. I don't use D6 just because there is no panels..

quotientix’s picture

Any idea, how long the portation will take?
I've been waiting for it for month!

Keep on truckin! We're looking forward to the D6 release!

NikLP’s picture

Subscribe (bah)

luckysmack’s picture

subscribing

japanitrat’s picture

subscribe

jivmuk’s picture

Awaiting for this module. Subscribe.

Anonymous’s picture

subscribing

Michelle’s picture

You folks just need to peek at the project page now and then. All this subscribing just bumps the issue up for everyone and then we need to come here and see what's been said only to find someone else subscribing. Really, just look at the project page every once and a while. Once the 5.x line has an RC, the 6.x line will get started.

Michelle

rtackett’s picture

Subscribing. I wish drupal would add the ability to subscribe to a thread without participating in it, then give the user the option of how often to receive thread updates.

If this exists and I am missing it, please let me know.

webchick’s picture

It would exist, if people spent their time working on #34496: [meta] Add Flag module to allow users to subscribe/unsubscribe without posting a comment rather than complaining that it doesn't exist. ;)

hass’s picture

This 3 years old case seems not important enough... or nobody can earn money with it. :-)

bennos’s picture

subscribing

hoecake’s picture

Version: 5.x-2.x-dev » 6.x-2.x-dev

subscribing ...

ddyrr’s picture

subscribing

yan’s picture

subscribing

danyell’s picture

subscribing

gustav’s picture

subscribing

farald’s picture

Dumdidum... subscribing..

merlinofchaos’s picture

GOOD NEWS.

Yes I'm working on this.

BAD NEWS.

I'm tired of people bumping this issue. I'm closing it to comments. When I have something I'll check it into the HEAD branch. If you want to subscribe to something, subscribe to the Panels commit feed: http://drupal.org/project/cvs/74958

merlinofchaos’s picture

Status: Needs work » Fixed
Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.