Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
As part of a larger web project, I plan to contribute these modules:
- UUID resolver: resolves UUID under a system path just like node ID under a node system path 'node/%'.
- Feeds delete: allows deletion of objects in website using some mechanism in Feeds. This shall initially be facilitated via extra mappings (may expand to a full blown feed processor if sufficiently different from existing feed processors).
- Feeds UUID targets: adds new UUID-based targets and handlers to feeds processors. Initially, the targets will be taxonomy and nodereference fields.
- Feeds subset import: allows filtering of feeds to be imported per importer. This is partially in response to http://drupal.org/node/856136 in addition to our own concern regarding a feed type per content type to import for. I plan to use Views for filtering so that I don't have to implement my own filtering mechanism.
- UUID resolver: resolves UUID under a system path just like node ID under a node system path 'node/%'.
- Feeds delete: allows deletion of objects in website using some mechanism in Feeds. This shall initially be facilitated via extra mappings (may expand to a full blown feed processor if sufficiently different from existing feed processors).
- Feeds UUID targets: adds new UUID-based targets and handlers to feeds processors. Initially, the targets will be taxonomy and nodereference fields.
- Feeds subset import: allows filtering of feeds to be imported per importer. This is partially in response to http://drupal.org/node/856136 in addition to our own concern regarding a feed type per content type to import for. I plan to use Views for filtering so that I don't have to implement my own filtering mechanism.
Comment | File | Size | Author |
---|---|---|---|
#17 | 0001-Fixed-resolver-inclusion.patch | 18.67 KB | zhangtaihao |
#16 | 0001-Security-cleanup.patch | 10.02 KB | zhangtaihao |
#10 | 0001-Clean-up-for-CVS-Application.patch | 31.34 KB | zhangtaihao |
#9 | uuid_resolver.zip | 12.27 KB | zhangtaihao |
#2 | uuid_resolver-6.x-1.x-dev.zip | 18.54 KB | zhangtaihao |
Comments
Comment #1
zhangtaihao CreditAttribution: zhangtaihao commentedUUID resolver is here. See attachment.
Also, I've abandoned the "Feeds subset import" idea. At the moment, "Data Feeds" is more like it. It integrates with Feeds, Data, Views, Rules, etc. to facilitate a flexible feeds import framework without polluting node types. I am still debating which modules exactly to require and which ones to support.
The other modules are coming. I was wondering whether you could allow me to get going with at least this module.
Comment #2
zhangtaihao CreditAttribution: zhangtaihao commentedFor some reason, the last attachment didn't upload. I'm trying again.
Comment #3
pcambraThanks for submitting your CVS Application!
Could you please include a more extense description of what UUID resolver does?
From CVS Application requirements: http://drupal.org/cvs-application/requirements
Comment #4
zhangtaihao CreditAttribution: zhangtaihao commentedUUID resolver
The UUID resolver is a module that accepts a UUID under a registered wildcard menu path and redirects to the target object (i.e. node/term/etc.) the UUID identifies. It integrates with the UUID module to look up an object. When a page access hits the wildcard path with a UUID recognized in the system, the URL is redirected to the path of the target object.
For example, in a Drupal site
http://www.example.com
, node UUID lookup is registered on the pathuuid/%
. The site has a node:286acd2e-cd1d-11df-a386-005056812593
The following URL:
http://www.example.com/uuid/286acd2e-cd1d-11df-a386-005056812593
will be redirected to
http://www.example.com/node/2
Motivation
When publishing nodes as syndicated objects on a Drupal site (e.g. with Feeds), it normally has a canonical URL. The path of this URL is generally under
node/XXXX
. In most cases, the node ID doesn't change, so this URL remains "canonical" for the duration of the site.However, in a massive network of websites sharing numerous nodes, migration of a domain from an existing Drupal platform to a new one (e.g. website renovation) can become prohibitively expensive and difficult to coordinate, requiring the cascaded updates of the existing canonical URLs (containing node IDs) to new ones, even before the new URL is set up. The natural solution would be to use a common identifier in the URL so that the URL would be truly canonical.
Since UUIDs are by definition universally unique, it would make sense to use it as a canonical identifier in a URL. This way, whichever installation a node is on, the same node should have only one UUID. This module then assists in redirecting that canonical URL to wherever the node is locally located. The domain update can then naturally progress without forcibly switching on maintenance mode for the potentially extended duration of a multi-tiered migration.
Comment #5
zhangtaihao CreditAttribution: zhangtaihao commentedComment #6
KarenS CreditAttribution: KarenS commentedThis is an interesting concept. We're doing a bunch of work around UUID to be able to migrate and deploy content across sites and maintain things like references. I don't know if this project would solve my particular problem or not, but it looks like an interesting solution.
The code looks nice and clean, haven't actually tried it out, just looked.
Comment #7
zhangtaihao CreditAttribution: zhangtaihao commentedWell actually a few of us at the workplace have been banging our heads on the issue for the past two months. The primary problem through numerous attempts we failed to avoid is just the general lack of feasible core/third-party solutions to work using a distributed base data model. I suspect a lot of these problems will go away once D7 is able to fully utilize RDF and related technologies as its chief data interchange protocol. Then, we'd be able to plug SPARQL into everything!
On another note, we had almost succeeded in a distributed data architecture using Feeds when we ran into the need to #917678: Refactor code to use arbitrary types of feeds source in addition to nodes. We're almost definitely going dark with D6 until the possible backport, but I'd keep an eye on what's going on next there for D7. (Psst, I'm in the process of forking Feeds 6.x-1.x to do all of that just as a proof of concept to ourselves. I'll let you know when I make some headway.)
Then again, maybe this would suffice: http://github.com/kswan/super_nodereference
Comment #8
apadernoAs reported in Documenting hook implementations:
Why isn't the code using
file_scan_directory()
t()
.It's not an implementation of
hook_load()
.Comment #9
zhangtaihao CreditAttribution: zhangtaihao commentedThe module has been cleaned up (in places I was able to spot anyway).
Regarding point 10 above, I have now added documentation to
uuid_resolver_menu_alter()
to indicate that it "Injects menu callbacks for each enabled resolver". In effect, resolvers register a base path (specified in admin UI) followed by/%
, the callback for which trickles down to the resolve callback for a path to redirect to. Do you think this should be documented somewhere other than foruuid_resolver_menu_alter()
?Comment #10
zhangtaihao CreditAttribution: zhangtaihao commentedAlso, the guard for a resolver's base path can be found in a regular expression on line 354 of
admin.inc
.I've attached a patch for all the changes this round for convenience and clarity.
Comment #11
zhangtaihao CreditAttribution: zhangtaihao commentedI'd just like to find out if anyone is reviewing this at the moment.
Comment #12
rfayThis looks to me to be as good as anything anywhere in contrib.
zhangtaihao has been responsive and cooperative.
I think this application should be approved.
Comment #13
ilo CreditAttribution: ilo commentedI'm going to make a review, but just want to point you that runing coder before submitting the module would help a lot, actually there are still some issues discovered by coder that require inmediate action:
- string concatenation.
- coding standard on comments.
- } else { statements.
Zhangtaihao, can you run coder and fix only the issues raised by the review? (so I can do manual review of other issues being sure that there is no important changes).
Comment #14
ilo CreditAttribution: ilo commentedmm so, sorry, I just click edit before your submission, rfay. In fact, reviewing the code, apart from that noissy coder issues about string concatenation, everything looks fine. I agree with rfay and suggest to let this one go in, eventually I'll be using this module in the following days, so I'll be providing a testcase and some bug fixings, so an issue queue will help a lot to make this module go live for the 1.0 release.
Comment #15
rfayilo points out that uuid module is looking for co-maintainers. That would be a quick way in the door also. zhangtaihao, we welcome you here and think you can do great things in this area.
Comment #16
zhangtaihao CreditAttribution: zhangtaihao commentedThanks for helping to review the module! Actually, I was going to get xtfer to put the project on CVS. He got busy and this application moved forward. In any case I can now get some momentum on this project.
I've checked the code against both the latest stable and dev releases of Coder and have fixed all the problems it could expose. Annoyingly, I've always used to put a space before and after a concatenation operator. It's only after looking over many modules over in contrib that I've got the impression of there being no real rule about it. I've now pushed it to the github repo (if you're interested it's at http://github.com/anu-science/uuid_resolver). I've decided to leave this issue clean so this could move forward, but here's the patch anyway.
If there's anything else I need to do, let me know.
Comment #17
zhangtaihao CreditAttribution: zhangtaihao commentedSorry to pollute this issue again, but I found a bug and resolved it. So, to test the module, here's the latest patch in the serial.
Comment #18
MichelleNot sure if this is still RTBC. There's a couple of patches added after it was marked so. Setting this back to needs review. If one of the reviewers could check if it should be set back to RTBC, that would be great.
Michelle
Comment #19
rfayIMO this should be a go. It's not the code that we're RTBC'ing, it's the CVS application. zhangtaihao has well proven worth of the CVS account.
Comment #20
MichelleWell, then, there you go. :)
Michelle
Comment #21
zhangtaihao CreditAttribution: zhangtaihao commentedThank you very much!
Comment #22
zhangtaihao CreditAttribution: zhangtaihao commentedComment #23
ilo CreditAttribution: ilo commentedThank you all. I'll keep an eye on the project from now on.
Comment #24
rfay@zhangtaihou, Congratulations! Looking forward to your contributions.
BTW: We just leave issues in "Fixed" so that people can find them. Drupal.org automatically closes them in 2 weeks if there's no further activity. So you don't have to change the issue to closed (fixed).
Comment #25
apadernoComment #26
zhangtaihao CreditAttribution: zhangtaihao commentedAlright, I'll keep that in mind in the future.
For reference, the project is located at:
http://drupal.org/project/uuid_resolver