I use the Remote File module for a cck field displaying a remote image. It works with a known issue: images are reloaded on every edit http://drupal.org/node/395256
And as i do tests with lots of nodes and delete them afterwards, the images cached in filesystem become deleted too. Is there a way to tell filefield(?) not to delete them?
edit
Meanwhile found http://drupal.org/project/filefield_sources which works very nice on manually created or edited nodes. But there is no way to make filefield fetch the image on assigning the url to the place where it shows up when i let print_r($node) show it to me.
See also my post to this (wont-fix)issue http://drupal.org/node/590756#comment-2774472
Yes, there is.
You'd need to create an interface between your node and the file so when you delete the node, the file stays in place. Effectively, you're just deleting the association, not the file.
Perhaps this module saves to the files table and the reference to the file exists already.
You could develop a third party module that stores all your external files and has a GUI or some other interface to select them again for new nodes
Or, you could create a specific content type and save the files as separate nodes. Then you'd use node reference to join them.
Alternatively, the developer of that module says he'll add features if you pay him. However he does not guarantee it from what I can see :)
Related
I have a problem with references to an image not updating in pages that are using that image.
This is the steps that the users are reporting
go to /siteadmin#/content/dam/
on the "new" dropdown menu, select "new file"
select an image file that is a different image but has the same name as a file that already exists
upload the file and when asked that a file already exists, choose replace
activate the file when the upload completes
The problem is that when I check pub I can see the image is updated, and if I navigate to the path of the image, for example:
pub1.mypub:4503/content/dam//my-image.png
I can see the new image I replaced the old one with
the problem is that pages that were referencing the image, specifically the image component, still shows the old image. I've check flush rules, checked workflows and nothing seems to work
The one thing I noticed is that in pages that are referencing the image the path is like this
/content//_jcr_content/my-component/my-component-parsys/columns/parsyscenter/image.img.jpg/1538602163986.jpg
so it seems the path it is using is like a generated path and not the same path as this one: pub1.mypub:4503/content/dam//my-image.png
im at a complete loss, I honestly do not know what else to check, has anyone ran into this and figured out how to fix it?
this is on aem 6.3
the problem is that in pubs the image being referenced in the component does not update, and since it does not update in pub, it never updates dispatcher
You can try activating the referenced pages after the image has been published. Since the page on publish has reference to the previous image.
Does anyone know if it is possible to unregister a custom node type?
For example, I have created a custom node type say "mgnl:product", which is created on start up, then I want to remove this "mgnl:product" since I won't be using it anymore. Cause currently, even if I remove it from the xml, then on startup, when I try to add a content node in JCR Browser, I can still see this node type in the list.
You should find your custom type inside custom_nodetypes.xml. This file is located under ${magnolia.home} folder:
${magnolia.home}/repositories/magnolia/repository/nodetypes/custom_nodetypes.xml
Just remove the <nodeType /> definition corresponding to your custom type an restart server. You need to also remove it from your mgnl-nodetypes/magnolia-*-nodetypes.xml files, so it won't be added again.
Here's the scenario: I have admins updating images uploaded via CCK filefield. I also have emails going out daily with an imagecached version of those images.
So when an admin updates an image, filefield deletes the old image and adds the new image (renaming it - (adding a _0 at the end) if the filename is the same as before).
All fine and good in normal situations, but what happens to the images referenced in the previous emails that went out prior to the update? They disappear, leaving an unprofessional looking placeholder or gap (depending on the email client viewing them).
Is there any way I can set filefield to not server-delete the old images after an update?
In the case of an updated image of the same filename, it would ideally just overwrite the old image without changing the name, though that isn't as important as the first point.
The Upload File Replace (for filefield CCK) module should do what you need. Some more details about this module (from its project page):
This is a small utility module that automatically stops Drupal from renaming new files upload via filefield CCK. When 2 files with the same name exist, the older files will be renamed.
I've built a content type to handle document upload. My content type uses a Book node to handle directories/subdirectories and I would like to show a couple of Views that shows the directories structure. When clicking on a directory I would like to show, in another view, all the documents inserted in that directory.
Do you know any existing examples of Views/Panels? That shows a similar structure, as in the Windows Explorer, using Views2?
You can use this module: views_tree
Also tree-like can be built via argument handlers...
So I'm writing a Django based website that allows users select a color scheme through an administration interface.
I already have middleware/context processors that links the current request (based on domain) to the account.
My question is how to dynamically serve the CSS with the account's custom color scheme.
I see two options:
Add a CSS block to the base template that overrides the styles w/variables passed in through a context processors.
Use a custom URL (e.g. "/static/dynamic/css/< website_id >/styles.css") that gets routed to a view that grabs all the necessary values and creates the css file.
I'm content with either option, but was wondering if anyone else out there has dealt with similar problems and could give some insight as to "Best Practices".
Update : I'm leaning towards option number 2, as I think this will allow for better caching down the road. So it's dynamic the first time, gets stored in memcache (or whatever), and invalidated when a user updates their settings in the admin site.
Update: Firstly, I'd like to thank everyone for their suggestions thus far. All the answers thus far have focused around generating static files. Though this would work great in production, it feels like a tremendous burden during development. If I wanted to add a new element to be styled, or tweak existing styles I'd have to go through and recreate each and every css file. Sure, this could be done with a management command, but I just don't feel it's worth it. Doing it dynamically would add 1 maybe 2 queries to each page load, which is something I'm not worried about at this stage. All I need to know is that at some point I will be able to cache it without rewriting the whole thing.
I've used option #2 with success. There are 2 decent ways of updating the generated static files that I know of:
Use a version querystring like /special_path.css?v=11452354234 where the v parameter is generated from a database field, key in memcached, or some other persistent file. Version gets updated by admin, or for development you would just make the generation not save if the parameter was something special like v=-1. You'll need a process to clean up the old generations after some time.
Don't use a version querystring, but have it look first for the generated file, if it can't find it, it generates it. You can create a cron job or WSGI app that looks for filesystem changes for development, and have a hook from your admin panel that deletes generations after an update. Here's an example of the monitoring, which you would have to convert to be specific to your generations and not to Django. http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Monitoring%5FFor%5FCode%5FChanges
Could generate the css and store it in a textfield in the same model as the user profile/settings. Could then have a view to recreate them if you change a style. Then do your option 1 above.
Nice question.
I would suggest to pre-generate css file after colors scheme is saved. This would have positive impact on caching and overall page loading time. You can store your css files in directory /media/css/custom/<id or stometing>/styles.css or /media/css/custom/<id or sth>.css and in template add <link rel="stylesheet" href="/media/css/custom/{{some_var_pointing _to_file_name}}" />
You can also do the trick with some random number or date in css file name that could be changed each time file is saved. Thanks to this browser will load the file immediately in case of changes.
UPDATE: example of using model to improve this example
To make managing of those file easy you can create simple model (one per user):
class UserCSS(models.Model):
bg_color = models.CharField(..)
...
...
Fields (like bg_color) can represent parts of your css file. You can ovveride save method to add logic that creates css file for user (by rendering some template).
In case your file format change you can make changes in your's model definition (with some default values for new fields), make little changes in template and run save method for each exisintg instance of class. This would renew your css files.
That should work nicely.
I would create an md5 key with the theme elements, store this key in the user profile and create a ccs file named after this md5 key : you gain static file access and automatic theme change detection.