I'm working with a legacy application that's using Liferay 4. They have a bunch of files on display using the Documents and Media portlet. I can see all of these files listed but when I go to view them or download them I get errors. I even tried going into the Admin Console and got the same issue. I can see all the files listed but when I go to download them I get errors.
There are some recent files from last month that were uploaded and those files are able to be viewed. So I get the feeling something happened a few months ago that deleted these files. From what I've gathered the files are stored on the server and the file information is stored on the database. If that's true it would explain why the files are being listed but not view-able/downloadable; if they were deleted from the server but their meta-data remains in the database allowing them to be listed.
According to this page, https://www.liferay.com/community/forums/-/message_boards/message/6387093, the files should be under data/document-library but I believe that's only for Liferay 6.
So where are these files being stored for Liferay 4?
Default settings for a portal come from a file Portal.properties. For Liferay 4, I found this documentation:
http://content.liferay.com/4.2/doc/installation/liferay_4_customization_guide/multipage/ch01s02.html
It states:
#
# Set the directories where documents are stored. This is now deprecated
# because documents are stored in Jackrabbit.
#
dl.root.dir=/home/liferay/documentlibrary/root/
dl.version.root.dir=/home/liferay/documentlibrary/vroot/
and
##
## JCR
##
jcr.initialize.on.startup=false
jcr.workspace.name=liferay
jcr.node.documentlibrary=documentlibrary
jcr.jackrabbit.repository.root=/home/liferay/jackrabbit
jcr.jackrabbit.config.file.path=${jcr.jackrabbit.repository.root}/repository.xml
jcr.jackrabbit.repository.home=${jcr.jackrabbit.repository.root}/home
jcr.jackrabbit.credentials.username=none
jcr.jackrabbit.credentials.password=none
In newer versions of Liferay, the defaults can be overridden in the file portal-ext.properties or in the database.
You might look for hints at these places.
Related
I work in ExpressionEngine v2.11.9 and I am trying to replace a file with an updated version and want to keep the same name so I don't have to update all the instances the file is linked on our website. However, when I delete the file and upload the new version, it replaces it with the deleted older version. We have also been experiencing files that were deleted from the Asset Manager still coming up in a search for that document in an online browser. For clarification, we have not had this problem until recently. Previously, I have been able to upload the new version of this document and "replace" the current version and it updates. Yet, it has stopped doing that. Also, when I delete a file in the Asset Manager, typically the filepath is broken when trying to access it from the website. However, in this instance, after deleting the file, it still pulls up the deleted file from the website.
Please let me know if you have any questions or require more information.
Thank you,
Beth
Ok, I have never seen anything like this before and hoping someone else has. I just finished patching our Dev and Test servers to Nov2017CU (SharePoint 2013). Since then, any solutions that are using JS injection from Site Assets are not updating. I'll make a change to the file, the library reflects that I made the change, but when I attempt to load the page accessing the js file, the changes are not reflected. Hard refreshes and full cache cleans are not affecting it. If I close and reopen my editor (VSCode) my changes are gone. When I look at the version history, the current version doesn't have my changes, but the previous version does. If I try to revert to that version, it doesn't take (still shows the previous version of the file).
Here's where it becomes extra weird. I have deleted the entire file from the library. Reset IIS (heck, I even rebooted the server at one time). It somehow still loads the file. The file is no longer in the library, but the server is still serving it up to the browser. I have confirmed it is not getting it from another location as the Dev tools are showing the file is located in the Asset Library the file was deleted from. Even users who have never accessed the site before are still getting that file in their browser.
This isn't limited to a single site either. I have other developers in different sub sites (same site collection) that are having the same issues.
Anyone seen this before?
Looks like your web application has BLOB cache enabled which is causing files to served from the cache.
There are 2 ways to fix:
1) The heavy handed way would be to flush the BLOB cache using powershell commands mentioned:
$webApp = Get-SPWebApplication "<WebApplicationURL>"
[Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp)
This will flush all the files in the BLOB. Usually, the files are cached based on the max-age attribute value. So, that is the reason that your files are being served even if you had deleted it from the source.
2) The surgical knife approach would be to append a query string, like (https://sitecollurl/siteassets/app.js?v=1.1), to the file references (usually in master page, page layouts, webpart references, script links etc. wherever it is referenced). When you append a query string to the file, it will force the browser to download the newer version of the file. Would prefer this approach as it will not unnecessarily clear other files from BLOB.
We have an issue with Liferay: when we delete a folder from the Document Library, with some documents inside, the corresponding disk files are not deleted. They are still in place even when the folder is removed from the Liferay Trash Can, and their size is still the full file's size.
When we delete documents directly, this issue does not happen: files are removed from the disk as soon as the document is moved to the trash inside Liferay.
This is a great issue for us since we are not able to free up disk space (a procedure to find already deleted documents and remove their files from the disk would be useful).
The only similar issue I found is this one:
https://www.liferay.com/it/community/forums/-/message_boards/message/3399338 ; I already checked that the user running tomcat has the correct filesystem permission.
This issue occurs on two different environments (staging and production) with the same configuration.
Our configuration uses AdvancedFileSystemStore for the Document Library and our Liferay version is Liferay Portal Community Edition 6.2 CE GA2 (Newton / Build 6201 / March 20, 2014).
EDIT: I still haven't found a solution to this problem, but I was able to find and remove deleted files from the filesystem thanks to this app:
https://www.liferay.com/it/marketplace/-/mp/application/49321947
It lists all files existing on the filesystem without an entry in the database, and let you delete them.
I'm trying to remove sample data (Welcome screen and everything else) from my Liferay server.
I tried to:
remove all directories from the webapps directory except ROOT directory
create new (blank) portal-ext.properties in ROOT/WEB-inf/classes (there was no portal-ext.properties file)
search via Google :)
Nothing of the above helped. Thank you for your advices.
You might have configured a database, or are using the built-in demo hsql database. This holds all the regular data. If you've configured Liferay to access another database either remove the tables from that database or point to another one. There's also the document library that holds documents and images (the binary content). By default they all live in the data directory, on the same level as your tomcat directory (assuming you use a bundle)
A new blank portal-ext.properties will not help you, as it overrides all the standard values defined in Liferay. If there's no content, you're using all the default. And the file should rather be in ${liferay-home}, e.g. the directory that also has the tomcat directory in a bundle.
As you've removed all content and bundled webapplications anyway, you can also just install a new bundle in another directory and use it, pointing it to a new database.
What files can we modify so that our solution is still supported by Microsoft?
Is it allowed to customize error pages?
Can we modify the web.config files to use custom HTTPHandlers?
You can certainly edit the web.config file for your sites. The one thing that you should be aware of, however, is that when you start editing files manually on the file system, you will have to remember to manually make those changes across all servers in the farm (assuming a farm exists). In addition to this, when you edit files in the 12 hive, it's important to understand that you will be making a change to all SharePoint sites hosted on the server(s) for which the files were edited.
Personally, if I were going to create a custom error page, I would simply add a <customErrors> section to my web.config. I avoid editing any existing files in the 12 hive, but I have added files (though it's rare).
The customization of the error page is not very easy (or flexible). You can see an example here:
http://blogs.msdn.com/jingmeili/archive/2007/04/08/how-to-create-your-own-custom-404-error-page-and-handle-redirect-in-sharepoint-2007-moss.aspx
The web.config can be changed. I used my own HttpModules in addition to the original ones, but I haven't used custom HttpHandlers. IMO it should work if you don't change the original handler (i.e. if you add your handler for a specific type of file not handled by SP).
do not modify any pre-installed files in the 12 hive (Program Files\Common Files\Microsoft Shared\Web Server Extensions\12)... a service pack may update and overwrite any changes.
Anything in the Content Database (Masterpage, Stylesheets list in ~Catalogs) is available to modify (I would add, instead of update, in case a service pack changes anything) as it sits atop the file system, and is instantly available to any members of the web farm (newly added servers).
Any custom features, added to the 12 hive in the features folder, in a custom/non-microsoft folder (that is, inside the 12\feature folder, do not modify any preinstalled files, but feel free to add a folder for your feature and work within).
Custom features can be developed using the Visual Studio Extensions (VSeWSS), currently available for Visual Studio 2005/2008... benefit being that the output is a feature package (.WSP file) which is designed to be portable across SharePoint. Additionally, the .WSP files are just CAB files with a different extension, offering the ability to be explored by simply renaming them.
For site definitions, Microsoft has a good article about what is supported and unsupported. In short, the only change you can make to the out-of-the-box site definitions is changing the entry in the webtemp.xml file to hidden in order to prevent the site definition from appearing in the site template list. This is something many may be interested in doing.
You may also, of course, copy existing definitions and rename them in order to create new ones.
The complete list of supported and unsupported scenarios for working with custom site definitions can be found here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;898631
Here is the closest I can find to a official response from Microsoft:
http://technet.microsoft.com/en-us/library/cc263010.aspx