This was already discussed in the Search API BoF yesterday, and I think there were more in favor than against. The proposal is to move the Search pages module into its own project in contrib, Ivan Zugec has already volunteered to co-maintain it.

The reasoning is that, currently, the Pages module is lagging behind (not exportable, restricted in options, not using theme templates, several hard-coded assumptions, …) and (at least that's my feeling) is used far less than the much more flexible Views integration. Therefore, it's maybe not essential enough to be contained in the base package. Also, by splitting out the Pages module, it's release would be split off of the Search API module, and could do its stable release when it is really stable, not when the rest of the Search API project is. Adding a co-maintainer would, of course, also be a lot cleaner with a separate project.

Possible downsides: It would get a bit harder to just try out the Search API, as currently pages are arguably the easiest way to do so. On the other hand, at least once they are convinced, most people will have to download other modules anyways to use the complete power of the Search API (especially the Solr backend).

So, I'd be interested in getting some further feedback for this, see what others think. And if no-one heavily objects (with good arguments), I'll then probably do this in the next week or two (of course, before a stable release—see tag).

Comments

tomogden’s picture

I am very much in favor of this. In my (biased) opinion it is the most valuable component of the suite, and I already have a small feature patch I would like to contribute.

drunken monkey’s picture

I already have a small feature patch I would like to contribute.

There is nothing keeping you from submitting it now, it can be included just as well.

Wanted to post here, anyways: Anyone have an opinion on how to do this? When we create the new project and copy the current module version into it – should we then delete the module from the contrib directory right away? Or would a transition phase, with both being available but the "old" one giving some warning, be a better solution?

drunken monkey’s picture

Also, does anyone know whether there it's possible with Git to split out part of a repository and "export" all commits touching that part? You can show the log of submodules or single files, but can you also move this "history" to another repo? Or will we just have to start with a fresh repository?

tomogden’s picture

The Pages module only appears in the stable version repository. I don't see it or any of the contrib modules in the MASTER.

Shadlington’s picture

You want the 7.x-1.x-dev branch, not the master.

Ivan Zugec’s picture

I have moved the Search pages over into a separate module http://drupal.org/project/search_api_page. Also was able to split the git repo so the commit history has been saved. :) Good idea drunken monkey.

I'll test the module and create a beta release.

drunken monkey’s picture

Hey, hope you had a pleasant vacation!

Great that you managed to keep the history and already created the project. Could you please also add me as a co-maintainer there? I'll start moving the old issues for the component over there.
For the record (and for #1260812: Move "Database search" into its own project, which should soon follow): what are the commands to copy the history in that way?

I also committed a small patch to the old Search pages module here to notify people that they should use the new one. Tested it out and replacing the module works very smoothly. I think you should create a Beta release right away – after all, the module was in Beta already before and works quite well.

And then, before doing the RC1 release, we can remove the module for real and hopefully startle as few people as possible.

Ivan Zugec’s picture

Vacation was awesome :) I have added you as a maintainer and created the beta1 release.

Regarding the git stuff, I found this stackoverflow.com page http://stackoverflow.com/questions/359424/detach-subdirectory-into-separ....

All I did was this:

# cd search_api
# git filter-branch --subdirectory-filter contrib/search_api_page HEAD
# git reset --hard
# git gc --aggressive
# git prune

Lastly make sure you delete the existing tags, that's it.

drunken monkey’s picture

Thanks a bunch, worked great!

drunken monkey’s picture

Status: Active » Fixed

Deleted and committed.
Good thing, too – it was really bugging me during development.

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