Drupal 7 port

Currently we're working towards a stable 2.x branch that we can then port to Drupal 7 instead of continuously integrating a Drupal 7 branch. Then the upgrade will be largely based on Coder Upgrade: http://drupal.org/project/coder instead of a manual port.

But, this is not planned until the stable release of 2.0.

closing this; this is a roadmap task, not an active task right now.

10 weeks have passed from latest update. How far we are from stable 2.0 in order to start D7 coder port?

First, there is no ability to port until ctools has some sort of D7 release.

Otherwise, IMO, we cant even consider a D7 port until we are in beta (and preferably an RC). And even then, I would like to push the port back as much until the full release of D7.0, as the module is still somewhat of a moving target.

That said I have been thinking and plotting about updating the roadmap, tagging issues, and making it much more concrete on what needs to be done for a beta (and hopefully a release candidate). I have still have to talk with @tmcw about this in more depth. Overall, I think we are very close to a beta, and from there it should move rather quickly to a 2.0 release.

Subscribing...

Let's do this!

CTools is moving fast these days. There is a version on http://github.com/sdboyer/ctools containing a fairly stable version of plugin.inc, export.inc, export_ui.inc - what more do we need?

Just a good attitude and time!

Seriously, though. That is about it. If CTools is good enough to start moving on this, then we can at least start the branch and let people develop/create patches.

Here is the process I would suggest for doing this, so that we minimize maintaining porting of changes to versions, and dealing with any D7 API changes:

1. Get the core Drupal OpenLayers (DOL) module ported, since this is just a matter of CTools integration. Obviously we will have to still follow changes in CTools, but that is always true.
2. Tackle Views, sine this is an important part of the module and there seems to be a fair amount of work in te Views D7 branch.
3. Upgrade the UI module. This is going to be the most involved as far as making changes following D7, and this could also use some improvements that will utilize some of the D7 stuff.
4. Then fill in the rest.

We definitely will not make a release of the D7 version until D7 is out and a OL 2.0 is out, otherwise, just keep as dev, IMO.

@alex_b, if you are serious about this and have time to do this, I definitely don't want to stop that effort. I can push the code that is in the 6 branch over to a 7 so that you can start making patches, or if you are interested and is alright with existing maintainers, we can look at giving you commit access.

Also, to note, as far as workflow, if we do start a D7 branch, any appropriate fix in the D6 version will need to be tagged in the issue queue and eventually ported.

There's now a Drupal 7 branch in CVS. It is not functional and please do not submit bug reports about it until we've ported all of the initial parts, at which point we'll put a -dev release on /project/openlayers

subscribe

This is great news, thanx! Let us know when we can start testing :)

Hi @steinmb, you can use the CVS instructions for each project, specifically this one:
http://drupal.org/node/177400/cvs-instructions/DRUPAL-7--2

OK so it is ready to start playing with, yay! :) Is there upgrade path at this point migrating data from 6.2.x to test?

No - the Drupal 7 work is not ready to start playing with and there's no upgrade path currently. When there's a dev release, it'll be ready for very early testing.

Subscribe.

Actually I think it will become more and more important to get some timeline estimate for this module. I know that it is not possible to predict how long it takes to have 2.0 and port it to Drupal 7. However, we should assume many people who start a Drupal-based project will do so using Drupal 7 right now, as the betas are supported with upgrades, which makes it hard to argue for starting a Drupal 6 bases site now that will need to be upgraded to 7 soon. For all these people, it is completely unclear whether there will be openlayers available for their site in the near future, which makes it impossible to make a time-plan for their Drupal 7 based projects. All these folks need is some estimate, rough as in "about March", "end of next year" or "never" ;-)

Cheers, Lars.

Hi @grobe. Your concerns are very valid. It is hard to make plans without some sort of estimate off time. But Drupal 7, nor this specific project has ever really been able to have time estimates. This is the nature of open source, IMO. If you need something by some time, you have to get involved and help push it towards something. Don't get me wrong, this is a bad thing when you are a commercial organization with deadlines, but this is the tradeoff of using something for free that is mostly volunteer or project-driven.

For instance, I have been pretty dead on this project for the past few months and cannot see having any significant time until the new year. That means that I have little idea of how this module will shape up in the near future. We have outlined goals as far as what we want for releases, but having a timeline is very difficult unless I actually have consistent, committed time to it. I cannot speak for @tmcw, but I believe he is working on a project that requires the D7 port, but there may not be incentive for him to even release anything more than a dev version with it. This is the nature of project-based time (not to say that he doesn't put in lots of time otherwise).

All this to say that I (we) cannot give you a timeline on this. Maybe @tmcw can chime in about his work. But unless you are prepared to dive in and help out with consistent time, this is the best we can do.

it is completely unclear whether there will be openlayers available for their site in the near future

There will be if you make it be. The sooner you start the sooner you'll get it done.
Bright side is you'll have support from others, and if you don't have the skills but a budget, you'll have broad choice of professionals capable of doing it.

Hey grobe,

I made the initial push on Drupal 7 work for a project, but that deadline may be slipping some more. The port is in a state where the UI generally displays and you can configure map views in Views. So, it's in a state where you could start and spot-fix things until it's workable.

I'm probably not going to work on the port for quite a while, given that I don't have any Drupal 7 work lined up (and it is unlikely that I will ever work on D7 in the same capacity as D6), and I believe the same is true of strk and zzolo. Thus if someone's working on a Drupal 7 project that requires this module and can help port it, their patches would be much appreciated. However, given that all of the core developers aren't using Drupal 7 right now for anything of import, this work is not likely to proceed quickly.

In about two weeks, there should be a usable - that means ui, layers, layer types, behaviors, and views - not CCK or filters - version of OpenLayers for Drupal 7.

That sounds like a really great surprise. Let us non-deva know when we can be helpful, e.g. testing, translations, going through docs, providing with test environments. Thank you!

By two weeks, I meant around two days - for a rough version. There's now a rolling -dev release on the home page. Behaviors, layers, presets, and styles are ported. There are definitely still bugs.

Awesome work, @tmcw! Maybe I'll have some time to test it out and get back tot he queue in the next month.

Actual changes in the version so far:

• OpenLayers now provides a boxes plugin. At least one decent way of presenting maps without the openlayers-map-style runaround.
• OpenLayers filters is axed
• People with contrib behaviors will need to update the javascript structure to reflect the d7 behaviors stack. Otherwise most things are unchanged.
• OpenLayers CCK will be axed; geofield or another module may be the replacement

@tmcw even before I start digging into the code I just want to thank you for all your hard work! That also goes for every one else that have worked on the D7 port.

Okay: currently views functionality is broken, in the name of compatible with the new field api and a much-needed cleanup of the dirtiest part of OpenLayers. So, -dev releases will not be functional. Also, there's a very serious performance hit with the new core which may not be possible to resolve.

OpenLayers CCK will be axed; geofield or another module may be the replacement

Good to know.
I am very interested in some geo/location/address field for D7, for the purpose of a geo-based people search in a community site.
OpenLayers was the only geo module I found so far with a D7 release, so I thought this would be the first candidate we should try.

If we need to code the cck/fields-in-core stuff ourselves, fine. I just wonder where to start, and if we should do this from scratch, or build on some other module like location or geofield, and what should be the role of openlayers in that equation.

I would be happy for any advice, that would allow me to spend less time for research. Thanks!

I am very interested in some geo/location/address field for D7, for the purpose of a geo-based people search in a community site.

If the site isn't huge and the search can be simple (rough proximity to a point), then Drupal is a contender, but Drupal 7 will not be capable for.. at least two months. If the site is huge or the search is complex, don't use Drupal at all.

If we need to code the cck/fields-in-core stuff ourselves, fine. I just wonder where to start, and if we should do this from scratch, or build on some other module like location or geofield, and what should be the role of openlayers in that equation.

For a community site, you'd probably be doing geolocation via address/place. Thus, you should help OpenLayers Geocoder out by working on that - and probably implementing a lat/lon solution, since WKT fields will not work for search. The role of OpenLayers is going to be 'merely' map display and configuration, not data input or management, or extensions upon the existing Views query abilities.

So, the solution could be
* Some structural cck/fields stuff which can store address and lat/long data. The address fields can be included, or something independent to associate with. This stuff can be independent of OpenLayers.
* Widgets and formatters based on OpenLayers. There could be alternative widgets and formatters that work with other geo/map modules.

If the site is huge or the search is complex, don't use Drupal at all.

Ha .. this has been discussed forever now.

Well, here's what GeoField is currently - it's a very, very simple implementation of a fields-based geo module.

Ha .. this has been discussed forever now.

It should be discussed - if Drupal 7 isn't a project requirement, you should really nail down the reasons why you're going with it.

[off-topic]
Ok, for your information.
- the project is not commercial.
- there is no strict deadline, and probably it will take a lot of time to get it finished.
- from the group of people involved, the number of them with drupal experience is significantly bigger than the number of people with experience in something else.
- most of the people involved are not that interested in learning things that only work within this one project.
- drupal 6 needs content_profile to make cck fields available to user profiles. thus, we don't like it.
- we are having a technical exploration phase, and this is part of it :)
[/off-topic]

- drupal 6 needs content_profile to make cck fields available to user profiles. thus, we don't like it.

If I were you, I would really reconsider this making D6 a non-starter.

Closing - the D7 port is completed as alpha-quality code. Open other tickets for more specific things.

Is Drupal 6 going to be better than Drupal 7 for map heavy sites for the near future?

@dtarc: yes.

Subscribing

Not to be crass, but why subscribe to a closed thread like this one?

Because I just didn't notice it was closed.... I was working 16 hours straight and was half-blind at the moment.