* Convert all md5() to sha1 #723802: convert to sha-256 and hmac from md5 and sha1
| Comment | File | Size | Author |
|---|---|---|---|
| #100 | 909504-linkchecker-missing_schema.patch | 1.7 KB | polynya |
| #100 | 909504-linkchecker-redirects.patch | 1.69 KB | polynya |
| #99 | 965720-linkchecker-redirects.patch | 1.69 KB | polynya |
| #98 | 965720-linkchecker-missing_schema.patch | 1.7 KB | polynya |
| #85 | 909504-linkchecker-test.patch | 4.49 KB | polynya |
Comments
Comment #1
hass commentedWait for #562694: Text formats should throw an error and refuse to process if a plugin goes missing
Comment #2
mgiffordsubscribe. This is a useful module for checking major upgrades.
Comment #3
yukare commentedThose issue #562694 will not be fixed for drupal 7.
I really like this module and find it usefull. Anyone working on a drupal 7 version? I will start working on it.
Comment #4
hass commentedCode is in HEAD... but only 2/3 ported and it does not work. I definitely need help how to read the new "fields". The logic have changed and I have not found out how the APIs works. The remaining rest is not that difficult to upgrade, but if I cannot solve the "fields" stuff I cannot work on the rest.
Comment #5
yukare commentedI am working and at this weekend will make a patch to you review.
The code in the head is not 2/3 as you said, it is much more ready than this.
Now i can make it extract the links from body fields (and will be simple add other types of fields), run cron to see broken links, edit the broken links.
Just wait the weekend and we will have a working version(incomplete).
This is the code to list fields and get the value:
Comment #6
yukare commentedAs promissed, the patch is my current work:
* Updated the tests for drupal 7, and all they pass now.
* Can check the links from the body of a node and from comments.
* Can view the report of broken links, and the cron task to verify which links are broken is working
Need to do:
* Test the upgrade from drupal 6, i did not change the database, so maybe it works without any change
* Need to add another fields types to parse in the content(easy task)
* Need to work on the changing link in the case of a 301 redirect( i did not touch this part yet)
* Need work on node umpublish when the link report as 404 error( i did not touch this part yet)
What i want:
* Please create a drupal 7.x branch on cvs, so will be possible create tasks/bug reports for it.
* Review the patch, it is not ready to commit direct on cvs, because it may have some dpm call and things like this, when i clear my to do list, i will provide a patch ready to commit.
* Report anything that is not in my to do list above.
Comment #7
yukare commentedI will do a patch latter, so this is a update from last patch:
* Convert all md5() to sha1 - Done, but this cause the lost of upgrade path, so current you have to uninstall(really uninstall, not only disable) the module on drupal 6 and after upgrade, install it again on drupal 7
* Change the link on 301 redirect - Working
* Umpublish the node on 404 error - Working
Comment #8
hass commentedWe can run an update hook to recalculate all sha1 hashes from the URLs. This can for sure be done without a reinstall, but requires some patience on the upgrade (may be a very long batch process), or we can do this in the background via cron. Otherwise we could set all links to require immediate re-check. I'm not very happy about both, but staying with md5 seems no option for some US government rules.
I currently prefer a batch process in an update hook.
Comment #9
yukare commentedNew patch:
* No more warning on watchdog, report if there is any for you
* Add The patch at #1021384
* Search for links in text_with_sumary, text_long fields and replace in case of 301 redirect. Search but do not replace in fields 'text'
* Everything must be working as is in drupal 6 version
To do:
* Upgrade path :(
* Improve the tests(lot of things without a test)
* Replace the links in case of a 301 in field 'text' (must take care with the size)
* Write documentation using advanced_help format ?
Possible new feature:
What you think about parse user and taxonomy fields?I will work on this after we have a 7.x.1.0 stable, with the other new features i want and there is open issues for it(ftp link validation, views integration(upgrade existing patch to views 3)).
Comment #10
hass commentedRemove #1021384 from code! Do not add new features! I do not like to use advanced_help module in any of my projects. Translation support is awful and there is nothing complex to document.
Comment #11
hass commentedLooks like all core modules use 64 length for hashes... I'm not sure how long the new hashes could be. This is the upgrade code.
Comment #12
hass commentedIncorrect change from #1040474: Report relative links as broken when drupal is out of webserver root dir needs to be rolled back. As said - only upgrade and don't change code style, blank lines or logics, please.
Comment #13
yukare commentedThe size of hash is 43, but since core uses 64 must be a reason and i will keep at 64 then.
I will remove #1040474 since it was a error, sorry. It fixes a diff from my real site and my dev site, but will break things in another cases.
I can remove #1021384 but please consider its inclusion, it is a small path, all the tests passes with it, and it is a nice feature to have that will not change anything for who do not want use it.
Today i will do another patch with those changes.
Comment #14
hass commentedI'm very sure that #1021384: New link checker mode : internal only. will go in later, but for now we should upgrade only and than we can integrate other features. For review it would be much easier to review/commit smaller patches. For example I would love to review a patch that only change the md5 stuff. After we have the correct database we can go forward with cck/fields and the rest...
I have seen action.aid is 255 in size an saves the same hash like we. I'm very confused how big the field must really be... Maybe aid is much more bigger size than the data saved in this field. Maybe a core bug.
Why 43? Php docs say 40 on sha256. Why does base64 add 3 letters... Strange. Thought about using sha256 only...
Comment #15
yukare commented* removed #1040474
* add upgrade patch from drupal 6, the only way to do this is in a upgrade hook, if we use cron, it will make the module unusable after installation until all cron is run.
* keep the hashes using drupal_hash_base64, using sha256 will not make any sensible difference, it can be used in urls if needed(maybe with views)
I will not restart everything and create a bunch of small patches now which will not work(because all those changes are needed to make the module work), so this is my last patch until there is a drupal 7 release, when i will work on ftp and views support.
This time there is a zip file with the module too.
Comment #16
Anonymous (not verified) commentedsubscribe
Comment #17
mike503 commentedsubscribing as a d7 port of this is VERY much desired!
could there be an initial dev release or alpha which doesn't have the "extra fields" support that is making things more complex, and that gets put in later once it's been implemented? might be a way to get users to start testing the module's basic functionality + scan the normal "body" content areas (unless those got pushed off into the field API too now)
i for one do not *need* an upgrade path for sites i'm starting on d7. i don't know if that breaks a social rule that any version must have an upgrade path, but perhaps if it was dev, the upgrade issues could also be "coming shortly" too?
Comment #18
yukare commentedI simple do not know what is missing for a dev release, current the module have everything that works on d6 version, have support for the most of fields, whicj is am improviment from d6, have an working upgrade path from d6.
"might be a way to get users to start testing the module's basic functionality + scan the normal "body" content areas (unless those got pushed off into the field API too now)"
Yes, everything in a node that is not the title is now a field, but this works on d7 port.
"i for one do not *need* an upgrade path for sites i'm starting on d7. i don't know if that breaks a social rule that any version must have an upgrade path, but perhaps if it was dev, the upgrade issues could also be "coming shortly" too?"
There is an upgrade path.
Since was about a month and the developer did nothing about this, i will create a sand box project and commit everything in small patchs as he requested, may be he can put it on a official d7 version, and i will work in add suport for the link module, views and ftp.
Comment #19
mgiffordWell, we're in an age now of git, so you can just clone the repository & work from there.
I looked at your zip file & compared it to the existing releases (dev & stable d6) but didn't see a neat correlation between the two.
Took a closer look using meld and would really like to get a better sense of how you created your patch so that I can apply it against an existing release.
Generally, there'd be a d6->d7 patch that could be reviewed compared with the existing code. The files are moved around so it's harder to do this. It would then be reviewed by a few people before being marked rtbc and brought out as a dev release.
Doesn't always work like this in contrib, and I have no idea if the maintainer is still involved or not. However, often sending an email to somewhere other than the issue queue can help.
Thanks for doing this work. In my review of the patch it's clear you've spent a bunch of time on this and it would be great to see it brought into a d7 release!
Comment #20
yukare commentedThe path apply to cvs head(look at #3 and #4), now master in git, where there is a previous work started in porting to drupal 7, not in 6-dev or 6-stable.
Comment #21
hass commentedCould you guys stop stressing me, please? As said it's easier to review/test smaller patches than one monster patch. If you do not like to provide smaller patches the review may take much longer.
Comment #22
yukare commentedAnd the patch at #1021384 which is small and you did not commit? and the pathc about views which is important and you did not commit?
I will not work anymore on this, is a good module, but you do not care about it. I have views 3 and ftp working, but if you want i redo all the patch and make everything from start again.
I really to do not what is so hard to review in this path, and more because it is agains a now working version, as the drupal 7 port do not work on git.
Comment #23
hass commented#1074740: Eclipse: How to commit code back to branches? and #1074746: Eclipse: How to create patch for branches?
Comment #24
hass commentedAs said earlier - don't mix patches! Remove #1021384: New link checker mode : internal only..
Comment #25
hass commentedSo, I've found the time to do a code wise review. This is a very big list. Patch cannot committed how it is today.
We need to remove all this entries if there are no classes defined in the PHP files. No idea why this order has been changed.
linkchecker_update_7001 make it 64? This is inconsistent.
Looks like this patch is not against latest DEV.
After 7001 the next update hook number is 7002, not 7004.
Trailing spaces need to be removed.
count(*) is VERY expensive for INNODB and should always be written uppercase with the column name e.g. COUNT(lid)
Code style is not good. SQL upercase...
Code style...
Why has this been changed?
%linkchecker_linkrefences to functionlinkchecker_link_load($lid)Patch is difficult to read, but 200 is handled like 304. Patch looks there is a difference made now. Rollback.
Trailing space
"Replace links in subject." Don't be lazy, make periods if sentences are finished and start with uppercase first.
Trailing spaces and code style. Remove empty lines and make periods.
Text style
Unpublished nodes will not checked for broken links! We don't do the extraction on insert.
Trailing spaces.
Needs documenatation what the function does and how it works.
Text style
Code style. Don't make newlines.
Codestyle: No newline
Text style.
Code style
Don't mix up patches! Roll this out!
Patches mixed.
???
Wrong indention?
Make sure this is a 100% clone of core with exclusion added. Unverified yet.
Text style
Duplicated line
Text style
Duplicated line
Remove line break!
"edit link settings" is an internal permission name. Need to be kept lower-case.
Period missing.
Never use double quotes if not absolutely required > code style.
Looks like a change that is cause by the wrong menu change.
Trailing space.
Invalid newline.
Invalid newline.
Powered by Dreditor.
Comment #26
yukare commentedLet me start it again.
I have created a sand box project at http://drupal.org/sandbox/yukare/1106574 now that we have git on drupal.org and will work on a patch there, once the patch is ready, you commit it and i remove/abandon that sandbox.
I will make all changes from d6 to d7 in many small commits on the sandbox, one for each change, so will be easy to review but put only a full patch here, is that ok for you?
I will fix all codding style things. One of it, i was breaking long lines into two, if this is wrong i will not do it anymore.
Some questions about your review:
The patch is against head, as you said in #4, do you want it against last 6.x-dev ?
Sure, and i need to change it. It was because i was working on the update, and once a 7002 update is done on drupal, i can not run it again, so i changed to 7003 and 7004, and forgot to change it again to 7002 before make the path.
Ok.
I will fix this and all other coding syntax in sql code. SQL functions must be uppercase. There is any other way to count records that is best for INNODB?
This is missing documentation and i will make this change clear: drupal send the message 200 for redirected code 301. If a site redirect to another place (301 code) and drupal can read the new address, drupal returns a 200 code(not a 301)(maybe a d7 change) AND a redirect_status of 301
There is not publish/umpublish on drupal 7, only save/delete, so i can test on save if it is published when the node changes.
Ok. It really need documentation. Since fields on the core, the way to get information on a field for a content type/block/comment(may be we could verify user profile fields in future) is near the same, so i moved it to a function.
Comment #27
yukare commented"Looks like this patch is not against latest DEV."
Now i understand what was wrong. There was some commits on HEAD(now master on git) after i started to work on the path.
Comment #28
hass commentedhttp://drupal.org/node/360052 and subpages are the forcing rules. Nobody needs a sandbox, but a very clean patch is absolutly required. I will not commit patches where every 2/3 lines have code style issues or if the patch adds other new bugs or mixes patches that are under discussion like #1021384: New link checker mode : internal only.. Bugs need to be whiped out before a patch gets committed - not afterwards. As suggested, smaller patches may make the review easier - at least if I need to comment every 2/3 lines.
Comment #29
yukare commentedAs requested, a small patch, it is not the full port to drupal 7, but one task: parse all nodes content, get the urls and add it to database. To test it, just press the buttom "Clear link data and analize content for links" on admin page.
I hope i fixed all issues you pointed in this part of the code.
This patch is build on master git branch using "git diff" so apply it with "git apply [patch.name]".
Comment #30
hass commentedPlease don't attach patches with numbers on the end of they will be ignored... :-( Buggy testing infrastructure...
Trailing whitespace
Trailing spaces need to be removed. See Drupal code style. I suggest to enable auto cleanup trailing white space in your editor...
Why is there an @? We write E_ALL save code and this may hide possible bugs. It must be avoided under all possible circumstances.
We don't make such line breaks. See Drupal code style.
Blank line required - see Drupal code style
Tabs need to be spaces
Upper-case first, period
Powered by Dreditor.
Comment #31
hass commentedWhat about the other CCK field types that partly needs special handling? They seems to be missing in the patch!?
"followning" -> typo
"because only of the two options will be set" may missing a "one".
Powered by Dreditor.
Comment #32
yukare commentedI did not know about this.
We will always have $field['bundles']['node']) or $field['bundles']['comment'] or none of then, but never both of then. I will test before if they are set and if not, i will create it as an empty array, so i can remove the @.
When i did the big patch, they do not have a drupal 7 version, but now weblinks and link have, i will install it and fix the patch to add support for it. The links module do not have a drupal 7 version(stable or dev).
I did not used tabs, maybe my editor inserted it. I will change the option to convert tabs to spaces and see if there is a option to show tabs, so i will not do this again.
Thanks by your review and i will fix all this before posting a new patch.
Comment #33
hass commentedThe most important field module to support should be http://drupal.org/project/link. There is a release. The rest can be done later if currently not available.
Comment #34
yukare commentedThis patch:
* I set my editor to use 10 spaces for a tab, so i can find easy if there is one, and i removed all.
* Set the editor to remove trailing spaces, so there is not anymore on patch.
* Removed the @ as requested.
* Add suport for the link module, thanks to new fields in core, this is a simple task.
* Found a bug in running filter(and fixed it).
Comment #35
hass commentedThis one looks good from code style.
For the reason of references it may be better to use return in the function... only for PHP 5.3
Is this really PHP5.3 compatible? As I know we should not use & any longer.
I have just checked the D7 version of this core function and it looks different. We need to clone the D7 function first and than add the blacklist stuff and other $cache_id name back. The function was also a 100% clone in D6, except a very few changes. I do not like to maintain other logic or variable names, so let's try to clone and follow core as close as possible. At least as this function is highly critical for security.
Powered by Dreditor.
Comment #36
kehan commentedsubscribing
Comment #37
yukare commentedNext Patch:
* Same features as the previous.
* The reference(&) issue: on php 5.3 it can create a warning E_DEPRECATED but i think we can use it, because the drupal core use it in so many places.
* _linkchecker_check_markup now is a clone from the version in drupal 7 as requested, I just change it to have the blacklist of filters working and the cache_id to have "linkchecker:".
Comment #38
hass commentedSomething I do not really understand here is: You push $type to the function, but you are not using it for
$field['bundles']['node']as$field['bundles'][$type]. I guess this could simplilfy the code and make it much more re-usable with blocks or other types with fields will be used in future!? Otherwise I will commit this now to get things forward, but could you explain this, please?Comment #39
hass commented7.x-1.x branch has been created. All patches should be made on top of this branch from now.
Comment #40
hass commentedRemoved comment as this unmatched patch segments seems to be a EGit bug
Comment #41
hass commentedComment #42
hass commentedHave you tested
$text_items[] = _linkchecker_check_markup($item['url'], NULL, $entity->language);with link module field? I'm not sure what filters will be applied to this field. I have no clue if filter_fallback_format() contains an URL filter - I guess not. This seems not reliable and broken!Comment #43
hass commentedThis is the patch that has been committed. I have changed the code, please review.
Comment #44
yukare commentedfilter_fallback_format() return the "safe" filter to use, in the case the default is plain_text, which adds <a> to urls and is parsed by linkchecker, i have tested it. But i see now, if the fallback changes to anything that do not run url filter in it, we won´t parse the urls from link module.
Comment #45
hass commentedPlain text means "show as is" and no urls?!?
Comment #46
hass commentedChanged linkchecker_parse_fields() params and fixed broken code I have broken. Are you familiar with Entity API? I'm asking me if this may replace linkchecker_parse_fields() or can help us in other places a lot!?
Comment #47
yukare commentedSome of the changes you done break one thing, it will not work with comments, the line that was:
$text_items = $text_items + linkchecker_parse_fields($node, $node->type);$node is a object, but $node->type is not always 'node', it is a drupal content type for bundle, may be the name of content type like page, book, mycreatedcontenttype, comment_page, block.
We can not test by $entity->type because this only works for nodes, when we use comments it is $comment->node_type, this is the reason i pass it to function, and it may be another for any possible entity type like node, comment, block, user.
Can i revert this change on next patch please?
Comment #48
hass commentedThat's very bad, but see latest code and commits, please. I fixed many bugs from #15 patch. We need to extend the function params than. Type is not "node". I found this while testing... It's "page" and other stuff. That's also why I'm asking for enity api.
Comment #49
hass commentedComments feature has been upgraded. Now we need to upgrade blocks and status code handling.
Comment #50
Huwiler commentedI looked over the linkchecker source and I think it checks only the title texts, so I tried to fix it. Because I'm new in working with Drupal, I don't know if my changes improve the code, so what do you think about this two changes:
File: Linkchecker.module
function linkchecker_parse_fields($entity, $type):
from:
if (!empty($field['bundles'][$type]) && in_array($type, $field['bundles'][$type])) {to:
if (!empty($field['bundles']['node']) && in_array($type, $field['bundles']['node'])) {and in the function _linkchecker_add_node_links($node, $skip_missing_links_detection = FALSE):
from:
$text_items = $text_items + linkchecker_parse_fields($node, $node->type);to:
$text_items = array_merge($text_items ,linkchecker_parse_fields($node, $node->type));Comment #51
hass commentedThis seems all wrong.
Comment #52
jeffwidman commentedsubscribe
Comment #53
FlavioHuesler commentedI think the problem is that we do not know the entity type.
see: http://drupal.org/node/1042822
Comment #54
FlavioHuesler commentedWhat about the workaround by using hook_entity_load?
and then using the following if statement:
Comment #55
hass commentedMaybe... When is this hook called? We need a solution that works in batches, too.
Comment #56
FlavioHuesler commentedSaw it in the entity.inc
called by DrupalEntityControllerInterface::load()
Comment #57
rodrigoaguilerasuscribe
Comment #58
Starminder commentedsubscribe
Comment #59
hass commented@Flavio: feel free to share a well working patch
Comment #60
yukare commentedPlease give a look at this patch and tell me what you think about it, but please, this is not a patch ready to commit, it still need more work.
It fixes the tests, but i need to add a test to replace a link when there is a 301 redirect.
It change the link when there is a 301 redirect. About the big change in 200 code handle: when there is a 301 redirect, and the new url exist, drupal gives a 200 code(not a real 301 as drupal 6) AND a redirect_status of 301, so a 200 code can be a real one, or one after a 301.
For anyone that want to help: please use this patch and test it on a copy of your site, and report anything that do not work in the same way as drupal 6, so i can see what is missing.
Comment #61
bowersox commentedsub
Comment #62
erikwebb commentedsubscribe
Comment #63
jrbeemansubscribe
Comment #64
skwashd commentedsubscribe
Comment #65
SanFeda commentedsubscribe
Comment #66
bryancasler commentedsubscribe
Comment #67
skwashd commentedUpdated title so it makes sense in lists with other (unrelated) issues.
Comment #68
hass commentedBullshit removal
Comment #69
mike503 commentedsubscribe
Comment #70
rt_davies commentedsubscribe
Comment #71
rvilarSubscribe
Comment #72
skwashd commentedFixing title so it isn't "bullshit" in dashboards and tracker lists.
Comment #73
hass commentedComment #74
FlavioHuesler commentedIt would be nice if you could have a look at this small patch.
Changes:
- added the entity_type property: The hook_entity_load (as it says) is called when an entity is loading. Therefore hook_node_insert has to invoke it manually.
- two errors fixed with if(empty(...))
- added $link = new stdClass(); prior to accessing uninitialized objects
Comment #75
yukare commentedFor me, this $entity->entity_type is a missing thing from drupal api, it is so much usefull that i do not know why it is not in drupal.
Comment #76
FlavioHuesler commentedWell it looks like they work on it:
http://drupal.org/node/1042822#comment-4574054
Comment #77
bluegray commentedsubscribe
Comment #78
hass commented@yukare: have you reviewed the patch in #74? Are you still working on the other stuff?
Comment #79
yukare commented#78
I have got some code from the patch at #74 and joined with my patch at #60, please review and commit my patch here and give credits to FlavioHuesler too.
#74
"added the entity_type property: The hook_entity_load (as it says) is called when an entity is loading. Therefore hook_node_insert has to invoke it manually."
This is usefull only if we make all changes to not pass $entity_type in any function, but other changes are here, those changes that fixes warnings are always welcome.
Comment #80
hass commentedThere are again some issues with tabs. Additional to this I'm wondering why we need $link = new stdClass(); db_query() should always save an object into the variable, if I'm not completly wrong. Therefore the object should already been initialized, but is empty - or is this wrong!? Latest patch is missing blocks logic to complete all stuff if I remember correctly.
Comment #81
yukare commentedI will look about tabs, sorry.
When a query do not have results, the result is an empty variable, not a object, creating an empty object before trying to use it remove a warning about this.
if (!$link) {
//$link here is the same as a null variable
$link = new stdClass();
// without the prevoius line, there is a error about trying to create a object from a empty variable.
$link->urlhash = $urlhash;
Comment #82
FlavioHuesler commented#81
exactly
#79
True. $entity_type should then be used everywhere but I thought the idea of using $entity_type is better than using the entity type as text in the parameter.
I think you forgot this. I had once an error/warning because $languages[$node->language] was empty not $node->language:
- $url_options = empty($node->language) ? array('absolute' => TRUE) : array('language' => $languages[$node->language], 'absolute' => TRUE);
+ $url_options = (empty($node->language) || empty($languages[$node->language])) ? array('absolute' => TRUE) : array('language' => $languages[$node->language], 'absolute' => TRUE);
Comment #83
polynya commentedThis is a patch to fix a couple of bugs in linkchecker_link_edit_form which stop the "Edit link settings" from working.
Comment #84
polynya commentedThis patch is a port to Drupal 7 of nkschaefer's Views integration.
Comment #85
polynya commentedThis patch fixes a few problems in the LinkCheckerLinkExtractionTest.
Comment #86
yukare commented#83
Thanks by this.
#84
A really big thanks by this one, and a very good thing to have :)
#85
Parts of it are already on #79, or you patch is over the patch at #79?
Comment #87
polynya commentedI hadn't tried patch #79, it looks like it covers everything in patch #85.
Comment #88
hass commentedI've committed #79 now with a few code style issues. Some listed here. Let's follow up with the other patches now. The VIEWS patch in #84 need to get posted to #965720: Views integration for Broken Links report. This one have nothing to do with the D7 update.
Do we also need the "continue" here?
Has been removed.
I fixed these indentation bugs.
Comment #89
hass commentedWe need to remove the @ here or we may not see errors when they happen. It's a rule in Drupal not to suppress errors. Catch them and handle the error or make it more save.
Comment #90
hass commentedCommitted #83, THX!
Comment #91
hass commentedThese change from #85 has been committed. All other changes failed to apply.
Comment #92
hass commentedHow about this fix from #74?
Comment #93
yukare commented#88
Question about continue: this come from #74, if $entity->$name is empty, the rest do not need to run and may cause warnings, but i do not remember that i had warnings about this.
Thanks by removing that debug() and fixing the identation bugs.
#89
I did it wrong, we must not have @ anywere as you said, i will do a patch to fix this.
#91
The patch at #85 was done without the patch at #79, so most of the fixes at #79 about tests are too on #85.
#92
I did not had a issue without it, may FlavioHuesler can explain why it is necessary.
Please, can you consider making at last a dev release of it? For me it need work only on small things, so we need more people to use and test it before you make a stable release.
Comment #94
hass commentedThere is a dev... But not on project home.
Comment #95
hass commentedAfter reading all comments again this seems to be the remaining TODO list:
* #42, links module links not filtered correctly into URL
* #49, blocks upgrade missing
* #54, #74, 76# Review entity stuff
* #82, $languages[$node->language], $language can be empty!???
* _linkchecker_link_replace(): I'd like to get rid of all the error prone regexes and move to HTML dom. We can get this from http://drupal.org/project/gotwo where I've already done it.
* camel case variables introduced by patches in this case need to be wiped out.
* _linkchecker_unpublish_nodes() review how we can get benefit from node_load_multiple(). (low prio)
Comment #96
hass commented@yukare: Can you explain how it is possible that a block do not have "info" or "title" field defined?
Äh - nodes??? We hook into block save, not nodes. And how is it possible that a block do not have a format?
Here is an updated blocks code with caching enabled, but I still do not understand the comments.
Comment #97
yukare commented#95
I will look at this list this week and work on it.
#96
When you scan and when you edit a block, we have two different objects! For me this is a drupal bug, and is very strange, but is real. We can have $block_custom->info or $block_custom->title for the same title depending from where the block comes.
Because of this we have those ifs, to see if we have one case or another.
Comment #98
polynya commentedAbsolute URIs are specified for redirects by RFC2616 section 14.30, but many web servers use relative URIs. In these cases the response from drupal_http_request is error code -1002 and error message "Missing schema". This is not very informative and doesn't tell the user if the link is really broken.
This patch tries to build the absolute URI using the scheme, host and port from $link->url and the path set to $response->redirect_url. The new URI is used to get the response from drupal_http_request.
Comment #99
polynya commentedIf the response from drupal_http_request is code 200 and the redirect code is not 301 then the link is not updated in the linkchecker_link table and the code is left as -1.
This patch processes these links. They are successful if the redirect code is in the list "Don't treat these response codes as errors" and is in the range 300-399. Links with other redirect codes are failed.
Comment #100
polynya commentedSorry, the file names for patches #98 and #99 have the wrong issue number. Here are the correct files.
Comment #101
hass commentedDon't post unrelated issues to this case here, please. Ignored responds codes are not logged.
Comment #102
polynya commentedOK, I have created new issues for #98 and #99.
It's not clear to me what should be included in this issue. What about problems with blocks caused by changes in D7?
Comment #103
hass commentedIf you would read the issue or #95 you would know that blocks code has not yet committed.
Comment #104
geek-merlinmemo to me: subscribe and look for some time to help porting this great module!
Comment #105
geek-merlinComment #106
Gerben Zaagsma commentedsubscribing
Comment #107
stefanx commentedI would love to see link checker for Drupal 7.
Comment #108
stefanx commentedCorrecting assignment.
Comment #109
paulgemini commentedsubbing!
Comment #110
mike503 commented+1 subscribe
Comment #111
BigBrother2010 commented+1
Comment #112
astutonet+1 subs
Comment #113
nkschaefer commentedWhat's the status of this? It looks like the last time anyone made any changes was over the summer.
Since I don't trust myself to find and apply all the right patches, could someone please upload a zip or tar of the Drupal 7 version we have of the module so far? Or consolidate all the right/needed patches into one patch? Or even create a sandbox project for the Drupal 7 port of the module? This module is critical for my Drupal 7 site, and I'd be happy to work on this, test it out, and provide patches to get a working D7 version of Link Checker out. Just please point me in the right direction.
Thanks,
Nathan
Comment #114
mgifford@nkschaefer It's useful to run it through http://drupal.org/project/coder to pull out the obvious stuff and create a patch.
Once there's a patch to review and errors reported it's easier to find the remaining places required to make the upgrade.
Please give it a try and post questions if you run into difficult. Also, work from the git HEAD repository for most projects.
Comment #115
hass commentedThere is a dev, you don't need to patch anything yourself
Comment #116
mgifford@hass - damn.. or rather excellent! However it isn't listed here yet:
http://drupal.org/project/linkchecker
So probably in git but no release made from what I can tell.
Can someone make an official dev release for this project and then we can mark this issue closed & start tackling the bugs with the dev release individually?
Comment #117
hass commentedThere IS a dev. Click all releases.
Comment #118
hass commented* #82 FIXED.
* #98 core issue. Case has already moved over to core.
* #99 FIXED.
* #100 FIXED.
* Camel case variables introduced by patches in this case need to be wiped out. FIXED
* #49, blocks upgrade. FIXED
* #42, links module links not filtered correctly into URL. FIXED
Optional:
* #54, #74, 76# Review entity stuff
* _linkchecker_link_replace(): I'd like to get rid of all the error prone regexes and move to HTML dom. We can get this from http://drupal.org/project/gotwo where I've already done it.
* _linkchecker_unpublish_nodes() review how we can get benefit from node_load_multiple(). (low prio)
Comment #119
hass commentedRemaining optional stuff goes into new follow up cases.
#1388760: Performance: Can linkchecker benefit from (node|comment)_load_multiple()?
#1388756: Refactor _linkchecker_link_replace() to use HTML dom
Comment #121
hass commentedThis is a call for testers for final D7 DEV.
In last 6 weeks the patches in this case have proven to be unreliable and unfinished upgrades with many D6 specific leftovers. I've got some helpful feedback from a few guys about some easy to fix issues, but if there is more to fix we should know asap.
I believe it's now nearly bug-free and very stable code, but better safe than sorry.
Comment #122
hass commentedSetting fixed so it shows up in queue again.