Well Ryan (and others),
Autolink looks good (I haven’t used it, only read specs), but due to the nature of how it works, I now wonder whether it is the right starting point for what I want - I want to actually change the content in the database - no need to dynamically add the link as the webpage is created.
I’ll try to be specific about my needs here:
1. I want a plugin/module, that has an interface accessible in the MODx manager. The "interface" could be an additional tab somewhere on the main Manager navigation, or on the plugin page itself.
2. I will go to the interface, and see a search box and also some type of field to define which TVs to search. By default, we would search [*content*]. but the user has to be able to redefine this depending on the way the site was built or the specific need at the time of the search. - Any variable content that belongs to any or all documents should be potentially searchable.
3. The way the content is searched is really important, and the usability of the plugin for seo depends on this: Search needs to understand word stems, and word proximity. The best way to explain is by example, as I gave in a previous post. The user comes and says to herself, "I want to find all related phrases to the term ’grammar checker’". She should search for "grammar check", and expext to see in the results "grammar checking", "grammar checker", "check grammar", "check my grammar", "checking your grammar is easy", and so on.
This means the search has to be able to look for stems -s, -er, -ing, -ed, -es, -est, and so on. In my example above I am simplifying things, too - ideally, if she types "grammar checking" she should get "grammar checker", but we can tell users to reduce to the unappended form of words ("check"), if that makes the search easier.
4. Ok, the search results:
Results should be sorted by Document ID/alias, and
importantly, the results within each document should be sorted by the order they appear on the page (earliest to latest). Something like this:::
Doc 27 - http://example.com/alias
result 1
result 2
Doc 31 - http://example.com/alias
result 1
Doc 101 - http://example.com/alias
result 1
result 2
result 3
Now, above, the results just tell us that the term or a related term appears on that document. We do not yet now whether the term is currently used as anchor text or not. So, each result, should actually be classified in the results:
Doc 27 - http://example.com/alias
result 1 - linked [glow=red,2,300][edit][/glow]
result 2 - plain [glow=red,2,300][edit][/glow]
Doc 31 - http://example.com/alias
result 1 - plain [glow=red,2,300][edit][/glow]
Doc 101 - http://example.com/alias
result 1 - linked [glow=red,2,300][edit][/glow]
result 2 - plain [glow=red,2,300][edit][/glow]
result 3 - linked [glow=red,2,300][edit][/glow]
Now, the user can see the anchor text situation for the related terms on this page, and she can edit all phrases accordingly.
5. What does the user see when she clicks edit:
example 1:
Current Status: check my grammar
Add/Edit
text: check my grammar
href:
class:
title:
Save
example 2:
Current Status: <a href="http://example.com/alias" title="checking grammar" class="">checking grammar</a>
Add/Edit
text: checking grammar
href:
http://example.com/alias
class:
title: checking grammar
Save
In the above two examples, after pressing edit, the user sees a current status field, which shows what the current config is for this keyword/phrase instance, and then has four fields that are editable, and populated (or not) with the current config.
Once the Save button is pressed, the changes are saved to the database.
I think that is it for now. Any questions about the functionality, or even the use?
Basically, I will say that this is mostly useful for content management on large sites (from 100 to 1000’s and more of documents). Likely, such large sites have lots of unoptimized internal linking, or even none at all. Even smaller sites can benefit, though, from better flow of link juice (Page Rank, whatever) through the site, and this tool will make this a quicker and more manageable task.