I am using ModX Revolution and have installed spieFeed as a RSS Feed Reader. I want to display only the headlines with links in a div on the page. I would also like to set a maximum number of articles and sort by most recent.
I can't make heads or tails of the Usage instructions, or where in ModX I would edit the code. Thanks for your help in advance.
I'm not familiar with ModX, but search your files for this:
[[!spieFeed
and you should find where it's called. Note that spieFeed is based on SimplePie 1.2, latest version is 1.3.x. It may be difficult to do what you're attempting...
Duplicate the chunk "defaultSpieFeedTpl"
Edit the content of the new chunk to fit your need.
add &tpl to the snippet call using the new chunk [[!spieFeed? &tpl=myNewChunk]]
#Revent,
It's been updated to the 1.3 though, the http://rtfm.modx.com/extras/revo/spiefeed needed to be updated.
Related
I am using stormcrawler and I am wondering if there is anyway to limit qty of outlinks discovered by page. I am looking something like db.max.outlinks.per.page in Nutch.
Thanks in advance
Not at the moment but this could easily be added to JSoupParserBolt and maybe the Tika equivalent. Feel free to open an issue on GitHub.
I'm writing an app that uses the GitLab API, and I'd like to list the pages in the wiki. I can do something like http://gitlab/username/project/wikis/home.md to get the source of an individual file, and see all pages with http://gitlab/username/project/wikis/pages, but I can't do http://gitlab/username/project/wikis/pages.md due to a 500 error.
Is there a way I can retrieve the list of files in the wiki?
So there's now a GitLab Wiki API available which does everything I need:
https://docs.gitlab.com/ce/api/wikis.html
It can be used something like this:
https://gitlab.example.com/api/v4/projects/:project_id/wikis?with_content=1&private_token=yourtokenhere
Note; if this list is to facilitate a TOC (Table of content) for navigation purpose, you now have GitLab 13.5 (October 2020), which comes with:
Deep-level wiki navigation
In GitLab 13.5, along with the release of group wikis, we have another huge improvement in how to view and navigate the file structure of a wiki.
Currently, it’s very difficult to see where you are or understand the structure of a wiki if you have multiple folder levels. This makes it difficult to navigate, find pages, and mentally map your information.
With this release, we’ve introduced wiki deep nesting in the sidebar so you can see all of your pages and navigate accordingly.
See Documentation and Issue.
Possibly not what you wanted (and a bit late) but if you have modified your Sidebar (i.e. _sidebar) you can make a copy of it and then delete it.
You could also add link:pages[List all pages]
to your home page. That might avoid, somehow, the 500 you get from pages.md
I need to divide long content to sub-pages.
Rule for dividing: Heading1 (H1)
Cms-system: MODX Evolution
As far as i know, there is nothing in modx to use for this kind of problem.
I probably got to do this manually anyway, but i still would like to know if there is a way to do this in MODX Evo / Revo.
Edit:
I need to do this in MODX; sub-pages got to be actual subpages, and original page becomes to container.
Navigation will be done with wayfinder.
Edit2:
All done.. manually. Question still open, though.
This is not possible out of the box and I don't know of any extra that archieves what you want. You would have to write a plugin that acts everytime you save a resource and split up the content, create/delete sibling resources as needed etc. Sounds like a lot of work for what you want to archieve to me.
I suppose you have a look at the MIGX extra. It provides you with a TV with the possibility to store an indefinite amount of distinct TV content sets. Have a look at the documentation and Mark Hamstra's tutorial (with screenshots) to see how it is done. You should define one MIGX entry to consist of a text field for the <h1> and a rich text field for the content of the "subpage".
Afterwards, you can use form customization to hide the original content field and display your MIGX Tv instead.
I think, this is a much easier way to archieve, what you want, and can't think of any way, where you would benefit from actual subpages.
Edit: Sorry, I just recognized that you were asking about Evolution, not Revolution. My solution would work in Revo, but I don't think there's something like MIGX for Evo. Sorry, my mistake.
not 'out of the box' you will have to run your content through a snippet to parse it into separate divs or something that you can run some javascript on to possibly 'tab' the content.
If you need to show the 'subpages' in your navigation, you will probably have to use the gatResources extra to parse your content ~ which will be very expensive on resource usage.
You can (depending on how you're using the tree) just create actual sub resources under the parent resource, using Ditto or Wayfinder to build navigation for it.
If you can't use the tree like that (though from your description I think you can), you could also set up a number of template variables ("content1", "content2", "content3" etc) and show that with a simple snippet or so.
There is some precedent for search-engine-ranking-related questions on StackOverflow, so please don't close this question. It's programming-related to the extent that HTML META tags can be called "programming".
Here's the problem:
We make FogBugz, the software project planning and bug tracking suite.
Either we did a great job with our old documentation or a crummy job with our new documentation, but for most of the popular searches on FogBugz terms, documentation for our old versions comes up.
Here's an example. For context, our current FogBugz version is FogBugz 7. The top two results for that search are for FogBugz 5, which is positively ancient.
As best I can tell, there are several options for getting these results out of the top slots, but each has problems:
A NOINDEX tag, but what happens if someone is actually searching for help on an old version?
Finding the incoming links to the old documentation and placing a NOFOLLOW on them to deprive the old docs of PageRank. Problem here is that it's really fiddly to find the links to the content, rather than changing the content itself.
The unavailable_after tag, which is just a time-delayed NOINDEX, with the same problem of removal rather than demotion.
I just want these old documentation versions to stop competing with our current versions, without being completely unavailable.
An approach I used in the past (3 years ago)
Change the URL to your old documentation, and change your own links to point to the new url. e.g. abc.com/docs/fogzbugz/v5/xyz becomes abc.com/docs/fogzbugz/ancient/v5/xyz
Using the old URLs, implement a 301 redirection to your new v7 content. e.g. a request to abc.com/docs/fogzbugz/v5/GettingStarted.html is redirected to abc.com/docs/fogzbugz/v7/GettingStarted.html
In this way, existing links from external sites will take browsers to the latest documentation, and inform indexing robots that the page has moved.
Google will find the new links to your old documentation by indexing your site, but there will be no external links, thus reducing page rank.
Google will also find the new links to your new documentation, and as more sites link to it, its page rank will increase and so take priority.
This worked for me on a small scale (100 or so pages) site, and visitor attempts to view the old content rapidly dropped off.
If a user does land on a v5 page, how about the MSDN approach of explicitly stating the version that the page describes, and providing links to the equivalent topic in the v6 and v7 docs?
I would suggest that external links to older versions get redirected to the latest version - with some sort of note that if you really needed version 5 the link is here.
I think a lot of the problem deals with the fact that search engines give something a high rank if a lot of people are linking to a specific page. Unless you can get all the people linking to your old documentation, to link to your new documentation, then you are going to have a problem with the older documents being rated artificially high. In order to overcome this, you might need to change the way you handle documentation pages. One good way would be to always show the newest information on a particular topic, and then only by clicking on a link on the page, do you get to the older versions. Optimally, this would be the same page, with a different parameter, to state which version you want to get documentation for.
What about trying the MSDN approach? You assign a version tag to your pages. When this page is displayed, its version number is displayed as well. Users will be able to see immediately that this information is deprecated.
You may need to write some stubs for new version pages like "This problem has been resolved in the current version" so that the users don't have to think you didn't do anything in 5 years. Some writing work, some interlinking but it's doable for a limited number of problematic pages.
I have a list of URLs and am trying to collect their "descriptions." By description I mean what comes up, for example, if you Googled the link. For example, http://stackoverflow.com">Google: http://stackoverflow.com shows the description as
A language-independent collaboratively
edited question and answer site for
programmers. Questions and answers
displayed by user votes and tags.
This the data I'm trying to accumulate for the URLs I have.
I tried parsing the URL's meta-descriptions, however most of them are lacking a meta-description (yet Google and other search engines manage to get a description somehow).
Any ideas? Should I just "google" each link and scrape the data? I have a feeling Google wouldn't like this...
Thanks guys.
Different search engines have different algorithms to get the description out of the page if/when they are lacking the description meta tag. Some ignore the tag even it it's there.
If you want the description Google has, the most accurate way to get it would be to scrape it. Otherwise, you could write your own or look around on the web for code that does it.
These are called snippets.
Google use proprietary (and possibly patented) methods to garner this information, so there is no simple answer.
As you suggest, they will use meta-description information if it is there. (How to set the meta-information to help Google.)
They will also honour requests from the page authors to NOT include snippets. (How to prevent Google from displaying snippets) You should probably respect this too (as well as robots.txt, of course.)
You may have some luck with existing auto-summary packages, such as OTS.
You may want to check AboutUs.org (i.e. http://www.aboutus.org/StackOverflow.com).
But, there's little chance that the site will have an aboutus page and not have a meta description.
Some info that might explain how google does this:
Webmasters/Site owners Help
Adding a URL to google
I am not familiar with Google APIs, but perhaps there is an official way to get such information.
Interesting. some sources are better than others.
For "audiotuts.com" google has a worse description than AboutUs.com.
Google
Nov 18th in General by Joel Falconer ·
1. Recently, an AUDIOTUTS reader asked me about creative process. While this
is a topic that can’t be made into a
...
AboutUs.com:
AUDIOTUTS is a blog/tutorial site for
musicians, producers and audio
junkies! It is the sister site of the
popular PSDTUTS, VECTORTUTS and
NETTUTS.
I hate problems like these... they should be trivial but they aren't!
If you can assume English content, you can first look for Meta Description, and if that doesn't work, you can look for the first two or three sentence-like word sequences.
A product I worked on looked for the first P or DIV that contained more than one sequence of > n "words" delimited by periods. It would use the two or three sentence-like sequences, up to x total words, as a summary paragraph. It wasn't 100% accurate, but good enough for the average case. The number of words was adjusted a few times to eliminate things like navigation elements.