Port to Drupal 7

Well yet, iam not planning to switch over to D7 too early, so iam not eager to port it in the near future.

But if people like it, iam open for any patches or Co-Maintainers which would like to port it. Porting the module itself will be pretty easy.

Subscribing. :-)

I have my own dev server (read: my desktop machine) with Drupal installs runnning on it. I'm happy to help test out the module for D7.

I was looking into this yesterday. This wont be very easy.

To actually make this module easy for D7 we should switch over to be a field widget. As we dont have any DB queries at all in the code module, the port to PDO is rather easy though.

But we will have to deal with the theme-api changes, hook_perm changes and the changes regarding the revisioning.

I'll take a look into working on a port if I get the chance. This is one of the modules are are looking at for our new D7 project.

Hi, nice to hear.

Be sure you dont just start with it, this port needs good plans. I was looking on the port the Drupal 7 Code last week and its pretty complicated. AFAIK the only way to port this module is fork it internally.

The Drupal 7 version of taggind should be build on:
- Fields: Taxonomies are saved in fields, so thats exactly the way to go. The seperation between "field and widget" is perfect for the different UI puporses
- nearly all theme calls are changed due to the new "array" arguments
- The crud operations on taxonomies have been changed completely. Eventhough we actually only use the API fo D6 on top, this will need so care looking
- The way taxonomies work with revisions has been changed. the index has only the "last term", the field saved the version relation
- The tagging JS widget will mostly stay the same. its a Jquery plugin and thats what the good news are about.

So before you start, just take your time and plan steps here in issues so it does not end like with the content_modoeration D7 port, which is a fork completely.

Following, this is a really interesting module for the D7 projects I am involved in.

This work will need funding, as D7 is not on my roadmap yet and its way to much work for just doing it by the way.

Subscribing

Subscribing

This is still something that I'm looking to work on, but as usual, other stuff continues to get in the way.

subscribing

I want to be straight and fair, just to be sure people dont keep on subscribing and waiting for a miracle to happen:
There wont be a tagging port to D7 without funding, iam sorry.

That is difficult for anyone without unlimited pockets to deal with. It would be helpful if you, or anyone, were to put a budget and timeline to the work and utilize this thread (site) to pool resources. Other that a few people "subscribing" there is no way of knowing how many people are interested and if any are willing to contribute money to the code.

subscribing

subscribing

subscribe

subscribing. This thread is 1 year old. Has anyone done any work on this yet? Even a good starting point?

I created a
Chipin
for donation on the project page

I've started converting to D7. I'll just do the main module first. I'm pretty familiar with the new field & widget format as I have convert my 2 other modules CCK_List & CCK_Table.

There is 1 thing I want direction on. So in D6 you goto the Taxonomy -> edit vocabulary -> Check on Tagging widget checkbox. From then on any content type that has the vocabulary will have the new Javascript UI. This is hard to do in D7 as taxonomy are fields. Only solution I can think of is to have a special widget setting. See image (from manage field screen). This is example of what active tags module did. For every field, you select which widget you want to use.

I also think that a custom term field widget is the way to go. I don't see a need to force this on a vocabulary level, and a custom widget is easier. What used to be in the module admin settings can just get moved to the widget settings form.

Update:
#1 I have gone ahead and made the changes to the widget vs vocabulary level
#2 Update on D7 porting: Check https://github.com/iStryker/tagging/tree/7.x-2.x
Last commit:
Major overhaul of tagging and drupalwiki_tagging_suggest module. The rewrite of the code is almost done. What is left is the javascript, a little more coding, then cleanup. Then we will tackle the submodules. I have also restructure the directories (ie css files are now in the css folder).

Update:
Tagging and submodule Suggestion have been ported to 7. Checkout https://github.com/iStryker/tagging/tree/7.x-2.x

Thank you for your work iStryker, very appritiated.
But .... similar to the ~4x D7 ports of content_moderation - why dont people coordinate this?

see comment #6

Your port is a fork of the module. Basically, thats what all ports to D7 are when you dont rewrite them properly - and that is what was planned with tagging. The reason is fairly simple - iam not going to maintain two completely different versions of tagging.

Writing new modules is one thing, but maintaing them is just the other, more complex and time-expensive part. Iam sorry, but i cant just commit this port to the official git repo, even i really apritiate your inititive and work. If you are interested in how the module shoulw be rewritten to actually work for D6 and D7 or at least share a major codebase, open a new issue. It will involve a rewrite into OOP, also rewriting the UI ( extending it ) and some JS adjustments.

But all this will be done in D6 first, then actually ported over to 7 - otherwise we need to maintain 2 branches in the meantime.

subscribing

@EugenMayer, completely understandable in regards to maintaining two different versions of tagging. But in the same respect, holding it hostage until your ChipIn is met isn't really helping the community either.

Clearly iStryker has the desire to do much of the work you cannot - without funding. Would it not make more sense to mentor iStryker in the completion of a port in the manner you deem maintainable? Or perhaps adding iStryker as a co-maintainer?

Also I should clarify that no disrespect is intended, as a big thank you - for all your contributions thus far - is well deserved.

Well, i cannot just add someone to maintain a complete major branch just because he has written it. The truth for drupal.org is, a lot of people write new modules, but only a minor, a really small amount of them maintain them longer then 1-2 months after the first stable.

As i said, i fully respect the work of iStriker and i feel sorry for all his diligence. In fact, we have the funds now, thanks to german companies Compress and Lukow.
We will try to include the D7-code snippets of iStriker and if we succeed in this, he will be part of the people named for working on the port - no doubt. Iam very hoeful that his work is not just wasted but can included.

Follow ups: http://drupal.org/node/1211210

Thanks @EugenMayer for the clarification, also glad to hear you secured the funds (thanks Compress and Lukow).

The first working version is here https://github.com/EugenMayer/tagging

Would be great if you guys could start testing and report back :)

EugenMayer, the .info files are still referencing the 6.x-2.4 version and 6.x core, I am unable to enable/install the module.

"This version is not compatible with Drupal 7.x and should be replaced."

Also of note, when you hover over the description for Tagging it links to:
http://kontextwork.de/

Will edit the .info files and install later (have to run to work).

Hello, you can now test https://github.com/EugenMayer/tagging/tree/d7_infofile_patch

It is not very clear on the tagging project home page that your main development repo is Github. I submitted some patches and wasted time fixing bugs that you already did in Github 4 days ago. :-(

@ñull this is often the case with development (at least from what I can tell), always check out the issues first.

anybody yet tested the D7 branch?

Installed the version with the D7 patched info files OK. Everything seems to be running smoothly. There are a few Notices that may or may not need attention (I don't really know what they're for):

When creating a new page with a tag field (using tagging widget):

Notice: Trying to get property of non-object in drupalwiki_tagging_suggest_tagging_suggestions() (line 12 of /sites/all/modules/contrib/tagging/modules/drupalwiki_tagging_suggest/drupalwiki_tagging_suggest.module).
Notice: Trying to get property of non-object in drupalwiki_tagging_suggest_tagging_suggestions() (line 13 of /sites/all/modules/contrib/tagging/modules/drupalwiki_tagging_suggest/drupalwiki_tagging_suggest.module).
Notice: Trying to get property of non-object in drupalwiki_tagging_suggest_tagging_suggestions() (line 22 of /sites/all/modules/contrib/tagging/modules/drupalwiki_tagging_suggest/drupalwiki_tagging_suggest.module).

Saving a page with no tags:
Notice: Undefined index: #value in taxonomy_autocomplete_validate() (line 1533 of /modules/taxonomy/taxonomy.module).

From an ease of use perspective, could there be a refresh button on the widget to re-check the content and make tag suggestions without having to save and re-edit the page?

Is it possible to hook the Alchemy API in to this version? Or do we need to wait for the Alchemy module to become available for D7? I notice you had to pull Alchemy support out according to http://drupal.org/node/1000704

@35: Thank you for testing it, very appritiated.
I guess you are running php 5.3, thats why we did not run into those warings. We will care about those.
According to the alchemy plugin, we will no longer support it as a OOTB submodule, as the maintainers seem to not care too much about the issues. So if you can motivate those people once again or create a new submodule, just make it a drupal.org project - we will not actively work on the support. So you are free to implement it, of course :) (its pretty easy)

For all the others, please create issues so we can properly work on those bugs (eventhough there is no 7.x branch on d.0 yet)

dupe

Would you like us to create new issues with no version or just keep tacking them on to the end of this thread?

create new issues, take 2.5 as version. That would be great

@EugenMayer,

I've ran Tagging (and submodules) through Coder, and there are some minor/normal changes that are required.

Would it make sense to create an issue for each of these? Or simply commit as I am doing via github and not worry about reporting in individual issues?

Example coder updates to tagging.module:
https://github.com/capnjav/tagging/commit/15c749c25815d9611ff7f188a0cbb9...

Well no, dont create an issue for this, iam not that interested in those cosmetic things. Maybe we will merge those things if no conflicts arize, otherwise they will be fixed during the time.

I am closing this issue, as it has been created for a release that is now not supported.