Shallow problem with the way the link syntax is treated
Support Ticket
+issues
There are two operations that can take place between cards, linking and transclusion, both of which are first class scenarios. Transclusions are great but one can't live without linking.
One gives you a portal to travel to content that is somewhere else, the other gives you a portal for the distant content to travel to your location.
However in search they are not treated the same. While renaming, transclusions to that card can be renamed with it, but the links are never processed and stay the same.
The current implementation, using the double square bracket [[ for link syntax, is however ignored when renaming cards. If you create a card or plus card and transclude it you can rename it and the transclusions point to the new card. However if you link to it and try to rename it, the links stay the same, and the integrity of what you are trying to build fades away with time.
I've setup this for testing while editing content here on wagn.
See step 6 of Optimizing in the card below. I have included both a link and a transclusion to http://wagn.org/Wagn_on_Apache+public_folder_symlink_prior_to_1_13
If one tries to rename Wagn on Apache+public folder symlink prior to 1.13 to something else, the transclusion still works while the link becomes outdated.
Please note that I'm referring to this syntax [ Wagn on Apache+public folder symlink prior to 1.13 | whatever text one may want to appear in the link ] OR [+public folder symlink prior to 1.13 | whatever text one may want to appear in the link ]. Seems plus cards are supported here also.
To set up Decko behind an Apache webserver, we recommend using Phusion Passenger. In general, you will follow the instructions for deploying a Rack-based Ruby application.
Following the above example, your apache config might look something like this:
<VirtualHost *:80>
...
DocumentRoot /srv/mydeck/current/public
<Directory /srv/mydeck/current/public>
AllowOverride all
Options -MultiViews
</Directory>
</VirtualHost>
You will also need to make sure that the apache user (usually www-data) has read access to config.ru and read/write access to your log, tmp, and file directories
Optimizing
The above should help you get Decko working, but you'll have to do a bit more to make it fast.
- memcache. This is vital for a high-performing deck.
To configure Decko for memcache, add this to your Gemfile:gem 'dalli'
and edit config/application.rb with the following:
config.cache_store = :dalli_store, []
- mod_xsendfile. File and Image cards process permissions before sending the file. This makes that fast.
- mod_expires. Makes use of decko's non-expiring assets so images, stylesheets, and javascript don't slow down page loads at all.
- You'll need to enable mod_headers so that the ht_access will work (Headers directives)
The way I see it, there is no easy fix since we can't really process all links?! Or is this a bug?
Maybe if we provide a transclusion syntax like this { Wagn on Apache+public folder symlink prior to 1.13 | LINK: whatever text one may want to appear in the link } for creating links we can support this scenario easier?
PS. It would be nice to have it just the way it is now and have it rename.
links are supposed to auto-rename, too. I'll have to check, but I think the issue may be relative vs absolute references?
It's supposed to work on relative and absolute links, right? There should even be tests for both scenarios.
I note that it won't work on external links or free links, and you have a link to this same page as a free link (always external) in the +example part of this issue. That one shouldn't rename, but the others should.
I think we have some brokenness. I renamed Wagn on Apache to Wagn one Apache and it did not rename the inclusion that had this as part of the name. The link is relative, so doesn't include the part I renamed. I'm going to try a couple more cases. (and rename things back)
Now the link is absolute. Could that have happened in the rename process?
I think maybe there is an issue with renaming a part, but links vs. inclusions seem to be ok.
You'll have to make sure with your own testing (or try to assign this to one of your expanding team :) ), but there definitely are some oddities here. I think it is only links that do the relative to absolute change (when you rename the +X part of the whole name).
The short reply is that there are clearly bugs, but most of the handling of links and inclusions is shared, so I would expect problems to be shallow, not systemic.
(So I'll go ahead and mark this "answered", but we do need to do a system review of renaming cases and related test coverage)
Great! I thought this behavior was a design decision.
I've renamed the title from systemic to shallow.