D7 branch

Subscribing

subscribe

Subscribing

I would be willing to take this on, or to collaborate with some others... anyone else interested in sharing the load?

subscribe

Subscribe! Is anyone working on it?

Subscribe!!! Very need!

+1. very cool.

hope I can help

+1

+1

I made a 7.x version based on the original code, you can download and try, not fully tested, I just tested the several features we used.

I am just a newbie to Drupal even php development, so feel free to give me any advice on whatever subjects, bugs, inappropriate code, style, anything, I'll try what I can do to help.

@stanley.zhang
I don't think it is a serious issue.
I downloaded/installed the 7.x module, and when I enabled it, I get the following error:

DatabaseSchemaObjectExistsException: Table <em class="placeholder">domain_taxonomy_access</em> already exists. in DatabaseSchema->createTable() (line 629 of C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\sandbox\includes\database\schema.inc).

The table is being created twice perhaps?

This is a sandbox/dev site. The module has not been installed before. But getting back to the admin/module screen, it does seem to be activated. To verify if the DB schema has been updated properly, I do an update.php and it states:

No pending updates.

To be sure, I disabled the module and ran an uninstall on it. After that I enabled it and I got the same error message.

May not be a serious issue - may be something quirky with my install. I'll post an update once I have tested it out some more.

Update:

I tested this and I am not sure if it is working properly. So, only sandbox/development box, I have two sites:
mainsite.localhost
subsite.mainsite.localhost

I logged in with UID=1 at mainsite, and added two terms to a vocabulary. One of them, I set publish only to mainsite. Second one, I set publish only to subsite.

After that, I tried creating new content (on which the vocabulary is a field) and both the new terms are available on both mainsite.localhost and subsite.mainsite.localhost.

Am I missing something? Or perhaps the above issue I faced is causing issues?

@Vyoma

About the install error, please apply the attached patch, then uninstall the module and re-install it again.

As about the other issue, I didn't reproduce it. My terms displayed correctly after I set up the domain settings. Please be sure you didn't select the "Send to all affiliates" option on the term editing page; and keep eyes on the url, on my testing site, I have two domains:
- localhost
- drupal.ityin.net

but when I finish editing the content on drupal.ityin.net and click "save" button, the site always redirects me to the same content on localhost, didn't get time to figure out why, just in case you have the same problem with me.

@stanley.zhang

I took the module on #12 and applied patch on #14.
I uninstalled the module and activated the module.

The patching works in resolving the install issue. I do not get the DatabaseSchemaObjectExistsException anymore. The install process is now clean without any problems.

I'm now able to see an additional 'Taxonomy' tab under 'Domain' configuration screen. ( ?q=admin/structure/domain/taxonomy )

I performed a similar testing scenario as you mentioned above for two domains:
mainsite.localhost
subsite.mainsite.localhost

I have one vocabulary, say 'Category'.
I've one term "Term A" given access to only mainsite.localhost
I've another term "Term B" given access to only subsite.localhost
'Send to all affiliates' is de-selected.
At Taxonomy Domain Configuration ( ?q=admin/structure/domain/taxonomy ), I've set the Parent vocabulary to 'Category' for the content type, say 'Article'.

These settings were done with UID=1 and cache is cleared.

I login again using a 'reduced' role, say 'Author', and try adding content ( ?q=node/add/article ).

At the top, I get the following error:

Error messageNotice: Undefined property: stdClass::$nid in domain_taxonomy_form_alter() (line 91 of C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\sandbox\sites\all\modules\domain_taxonomy\domain_taxonomy.module).

Both 'Term A' and 'Term B' is available on both the sites: mainsite.localhost and subsite.mainsite.localhost

I'll try to dig in a bit further, play around with the configurations, and post if I have any updates.

I did some debugging using Firebug for Drupal.

Here is what i found out. When logged in as a non-admin, authoring user, and navigating to ?q=node/add/article I find that domain_taxonomy_query_term_access_alter() is not completely executed.

It checks for path_is_admin(current_path()) and finds it TRUE and returns without altering the term access query. For that reason, (I assume) it does not filter the terms in the category.

Is this by design/intention? Shouldn't terms be filtered in the content authoring form itself?

@stanley.zhang

I think I got it working.

Fix 1: Configuration
To fix the issue of 'Undefined property: stdClass::$nid' as I mentioned in #15, I removed the 'Parent vocabulares for node types' for the Content Type under question.

Fix 2: Code fix
To fix the issue with it not filtering as mentioned in #16, I updated the domain_taxonomy.module in domain_taxonomy_query_term_access_alter($query) as follows:

  if (path_is_admin(current_path())) {
    return;
  }

to

  if (arg(0)=='admin') {
    return;
  }

I basically looked at the 6.x domain_taxonomy_db_rewrite_sql($query, $table, $primary_field) function. The reason path_is_admin() returns TRUE is because, I had Admin Theme setup for content editing/authoring pages. Not sure if arg(0) is the right approach, but it allows the admin theme to be set of content editing, and also allows for query altering to take place.

Fix 3: Code fix
After the above 2 fixes, I could get the domain access based vocabulary term filtering working correctly. Only issue was that, once the content was saved and it was viewed (not edited), then it would through an undefined index error in domain_taxonomy_form_alter(&$form, &$form_state, $form_id) for $form['#node_edit_form']). Hence I changed:

if (isset($form['#node']) && $form['#node_edit_form']) {

to

if (isset($form['#node']) && (isset($form['#node_edit_form']) && $form['#node_edit_form']) ) {

By the way, I did not have the problem of redirection in my development box. It was staying on the domain where the content was authored.

I am attaching the patch (domain_taxonomy.20110708.patch) to be applied on domain_taxonomy.module for Fix 2 and Fix 3.

You should be able to apply this on tar.gz in #12 with the .patch in #14.

Let me know if these fixes work as intended.

Subscribing, because in D7 nodes and terms are not really relevant anymore, love to have term support on Domain.
Could you may be attach your complete working module in zip? Thanks a lot in advance!
Greetings, Martijn

@Summit - the zip & tar.gz (got renamed as tar._gz) is attached.

It contains:
#12 (stanley.zhang) - domain_taxonomy.tar_.gz
#14 (stanley.zhang) - patch-2011-06-27.patch
#17 (Vyoma) - domain_taxonomy.20110708.patch

Note though that it seems to work on my development box and I am yet to use it in my production site.

Anybody knows what is the process to get it committed here on the project page and start a 7.x-dev branch?

Hi,

I enabled the domain taxonomy module from #19.
Now normal taxonomy pages are not working anymore. In my case pages like:
[url]/taxonomy/term/6/edit?destination=admin/structure/taxonomy/regional gives now "page not found".

After disabling the module, taxonomy pages are normal again, so the problem is within domain_taxonomy.

Thanks for going into this!
Greetings,
Martijn

@Summit

Could you clarify which of the URL is giving a 404?

/taxonomy/term/6/edit

OR

admin/structure/taxonomy/regional

Ok - I think it was having issues with the term edit screen. Basically, my fix #2 mentioned in #17 had an error. So reverted it back, with an extra if clause:

  if (path_is_admin(current_path())) {
    if (!(arg(0)=='node' && arg(2)=='edit'))
      return;
  }

I've attached the patch for module in #19.
The full module is attached in zip and tar.gz format.

@Vyoma

Finally get time to look around the issues.

About the issues you listed in the #17, I can only re-produce the first one "'Undefined property: stdClass::$nid'", which is caused by non-existing nid field in $form['#node'] when adding content, I'd prefer to change the default value to true, cause I think when you set up this in the "'Parent vocabulares for node types", you probably want the domain settings to be load from parent terms most of the time. The original idea was to set this to true when adding content, but set to false when editing content.
'#default_value' => TRUE,

As about the second issue, can you please tell me what exact permission you granted to the 'reduced' role, I think I can't re-produce the problem because of permission settings.

About the third issue, I can't re-produce this either, and I don't see there is any bug in this line, but I found another issue in function domain_taxonomy_form_node_submit when tracing this issue, we need to re-write this function because of the differences in field management between D6 and D7.

The commiters of this project seems have abandoned this project, I think we can create a new project to start the 7.x branch.

Have rerewritten the function, I think we really need somewhere to commit the code

Hi,
@stanley.zhang: could you first please post the code here like @Vyoma did?
Hopefully you have @Vyoma patches included when working?
Looking forward to .rar file to test further.

Thanks a lot in advance for your reply!

Greetings, Martijn

@stanley.zhang, I agree. It would be good if we had a repository to work with.

I've contacted xanderz, the maintainer of this module, to see if he is ok to give us co-maintainer access. If so, then we can raise a Git access issue queue.

If we can get this, then I think that would be most appropriate since it is the domain_taxonomy D6 code base we started off with.

@Summit
Not yet include the code from Vyoma, will upload the code after Vyoma confirms the issues.

@Vyoma
Sure, it's great if we can contact with the owner of this project.
Plus, can you please confirm and give me more info about the issues you met? I just want to get a full view of this module and code, you know, I am only using very little features of this module, and I don't understand the real intention of much code yet, just migrate them from D6 to D7 accoring to the D7 API, so ...

@stanley.zhang

I am still waiting for a response from xanderz.

For issue #1, I'm not sure I understand. But then again, I'm just trying to trace and hack it to get it working first. :)

Note that for the issue #2, the "reduced" role just had content authoring permissions. But the root-cause, as I mentioned in #17, is the path_is_admin() call along with having the 'Admin theme for content authoring' enabled. When I disabled that option under 'Appearance', it was not a issue and worked as intended. So, I basically replaced it with following in domain_taxonomy_query_term_access_alter($query) function:

  if (path_is_admin(current_path())) {
    if (!(arg(0)=='node' && arg(2)=='edit'))
      return;
  }

Issue #3 - I did get that error - but that might be in conjunction with issue #1. So, once you get this rewritten function, I try to run it through my development instances and try to replicate again. I think we are now deviating on the code bases we are working on and perhaps that may be the reason it is acting differently?

Update 1:
I've opened a support request to get co-maintainer access to this project. #1230706: Offering to co-maintain Domain Taxonomy
As per guidelines, we have to wait for two weeks to allow for xanderz to respond.

Meanwhile, I've git-cloned the master branch to a sandbox project: http://drupal.org/sandbox/vyoma/1230710
Note that this means it has the 6.x code as of now in the 7.x-1.x branch. We can start working here in the interim if that is acceptable so that we can have proper version control as well as issue tracking.

@stanley.zhang - please let me know if it is ok for me to add you as a maintainer to that sandbox project, so that you can commit the code in for the 7.x branch. I could do it myself, but if you commit the code and when we eventually commit to the official module, it will retain the commit credits to you. If I do it, it will tag those commits to me (or that is how I understood).

Update 2:
@stanley.zhang - I have been able to commit your initial tar.gz file + first patch to this sandbox project, giving proper attribution/credits:

http://drupal.org/node/1230710/commits

So, as soon as you confirm you are ok with me giving you maintainer permissions on that sandbox project, we can continue working there. Once (and if) we get co-maintainer access to this official module, we can push the change set from there over to here, with all the VCS history. Let me know.

@Vyoma

Sure, your idea is good, please add me as co-maintainer.

I re-produced the issue #2 on your #17 post, I think it's better to use the following code:

if (path_is_admin(current_path()) && arg(0) != 'node') {
    return;
}

Please take a look at node_admin_paths() function in node.module, there are node/add and other paths besides the node/*/edit.

@stanley.zhang

I've given you following access to the sandbox project - Vyoma's sandbox: Domain Taxonomy D7 Port:

• Write to VCS
  Allows a user to commit or push to the repository associated with this project.
• Edit project
  Allows a user to edit a project and modify its settings.
• Maintain issues
  Allows a user to assign issues to other issue maintainers for this project.

I think that should be sufficient for us to collaborate on this effort, allowing you to commit any changes, triage issues, and make updates to the project page.

Regarding the code you suggested, I think you are right. Go ahead and clone+change+commit+push that to the sandbox - that way we can test if I have given all the correct permissions for you. :) Once we verify that, we can start tracking the D7 issues there until we get access to the official Domain Taxonomy project.

@Vyoma

I think I've comitted the changes, I am not familiar with Git, I only used Subversion before, not sure if it's correct, let me know if you find anything wrong.

@stanley.zhang

It does not look like the commits you did were pushed to the repository: http://drupal.org/node/1230710/commits

The last commit there seems to be from me 'Commit 878cb77 on 7.x-1.x'.

Git ( http://git-scm.com/ ) is actually quite simple once you realize that it is a DVCS - Distributed Version Control System. (The other DVCS I know of are Mercurial - http://mercurial.selenic.com/ and Bazaar - http://bazaar.canonical.com/en/ )

With this concept, you'll basically have multiple repositories. You can do commits, rollbacks, branches and tags on all those repositories, and that means you can do that on your local after you've 'cloned' the repository. The additional step you need to do in term in push (or pull) change-sets between repository.

Check the Git instructions specific to the repository here: http://drupal.org/project/1230710/git-instructions

Specifically look at the instructions in 'Routinely - Pushing your code back to the repository on Drupal.org'.

You might have done the 'git commit' but missed the 'git push' to origin.

Let me know if you are still have issues. If so, feel free to open an issue at that respository ( http://drupal.org/node/add/project-issue/1230710 ) so that we can keep this issue clutter-free.

@Vyoma

Finally done, actually the git-instructions are very good, but I read that before I logged into drupal.org, so... Stupid:)

@stanley.zhang

Cool - I see the pushed commit on the sandbox. Now we can collaborate over there. :)

@Vyoma
I would like to help with the development of Domain Taxonomy D7 branch.

@azovsky
Appreciate any help in this effort.
Please do checkout the D7 code from Vyoma's sandbox: Domain Taxonomy D7 Port - there you can:
- log defects/issues
- submit patches

I am currently busy on other things, but I should be able to review those there.

Thanks for your efforts - will be testing this.

subscribe thx!

subscribing

My co-maintainership request got approved - #1230706: Offering to co-maintain Domain Taxonomy

With that being done, in the next couple of days, I will be trying to merge the changes from my sandbox project into this official project and create a 7.x-1.x-dev branch for people to test.

The preliminary port to 7.x is now available in the development snapshot - http://drupal.org/node/1296776

Please note that this is not production ready, but is made available for testing.

Please report any further 7.x issue appropriately tagged in the issue queue.

As of this update, I do not see a reason to keep this issue open.

Great news Vyoma. Keep you updated.