I want to have the start page of the wiki of a project in GitLab as general start page for the project. Is this possible?
This isn't currently possible. The only views available which you can find in /profile/preferences are activity and readme.
This is possible because there's a bug in gitlab does exactly what you want, but only
for logged in users accessing
a public wiki-only project
So i guess „It's not a bug, it's a feature" ;)
Update
Having checked the example repository in the above linked issue, what you're asking for seems to be the default behaviour on gitlab.com now for wiki-only projects (which means you have to go into the settings and disable the repository feature).
I just verified that by setting up a fresh wiki-only project and it shows empty wiki page as homepage which was introduced in 12.5.
Related
In a project repository, I created a Wiki, but have renamed "home" to something else. Now, when I go to the Wiki again, it asks to create a "first" page because "home" does not exist; is it possible to specify the landing page for a project's Wiki (i.e. change "home" to something else per project)?
It is not possible (as of 14 Aug 2020). See documentation on the wiki.
The /home page appears to be the default wiki page, and if it is not created it seems that Gitlab will encourage you to create it every time you click the Wiki navlink. I tried myself to create a home page in a Wiki on Gitlab, delete the home page, then click on the Wiki again, and GitLab wants me to create the home page (although the other page that was renamed is still there).
What I recommend is to use the /home page as the landing page, and put a link to your other page on the /home page.
It does seem that this issue has been raised before, however, the GitLab team has yet to implement it as part of their codebase:
Old, original Feature Request
Open Feature Request (maybe this feature will be released soon)
I suspect that in the past, the default landing page was index.md, as indicated by these public-facing company GitLab landing pages, but there was still a forced default page:
Example 1
Example 2
I’m experiencing an issue with customization projects in Acumatica 2017 R2 Build 17.203.0029.
Specifically, custom screens, while in my project XML, are not visible within the customization project browser nor can they be navigated to once published (which occurs without error). This only occurs on my staging server. Everything works fine in my local dev environment and even on a different instance of Acumatica. My local dev environment matches the staging server in every possible way (Acumatica version, other packages, etc.)
Older versions of the same customization project have been published before and did not exhibit this behavior. It’s only after I replaced the project with newer version of the same project that I encounter the missing custom screen issue.
As shown in the screenshot below, remnants of the custom screens are present in the Customized Screens window. And the ASPX files are present and shown in the Custom Files window.
Screenshot of missing custom screen data
When I compare the “Edit Project Items” objects between the staging the server and my local dev version, they appear the same.
It it possible that the internal customization or sitemap tables on the staging server have inconsistent data? Is there anyway to rebuild them?
The solution appears related to the users roles config. I had not assigned access rights to the custom forms. Doing so solved the issue. The custom screens are now accessible by direct URL and are shown in the customization project browser. Maybe this will help someone else.
I had this same issue when trying to Deploy the customization to another instance.
To fix it I had to go to the site manager and change the URL of the new page
from: "/Pages/SO/CustomName"
to: "~/Pages/SO/CustomName"
I'm quite new in liferay and this must have been a very basic question.
Can we make site templates deployable as standalone component like themes? If yes how can we do this? Any help or content explains how to do this will be great.
Thanks
You can export and import site templates - they'll not be deployed like themes, but you can carry them from one portal to another. Check the cogs-icon in the top-right of the Site Template configuration screen in Control-Panel and you'll find the Export/Import Actions. The individual SiteTemplate's Action button also has an Export option available.
Another option is to get familiar with Liferay's API (learn ServiceBuilder for understanding the concepts) and examine the sourcecode. A good starting point is the ancient 7cogs sample code (not all will compile as-is, this article is for an older version, but the principles will help you to understand). Also note that the article links a second follow-up article. Everything in Liferay is done through the API and you can literally automate everything - you'll "just" have to find the proper API and use it.
Site templates can be deployed in a plugin via the use of Liferay's Resources Importer.
See: https://dev.liferay.com/develop/learning-paths/themes/-/knowledge_base/6-2/importing-resources-for-your-theme for more information.
You can probably find some some examples here: https://www.liferay.com/marketplace/-/mp/category/15828894
I am in a process of learning gitlab and have created some test projects.
But I just cannot figure out how to delete these projects. I do not see any "Dangerous Settings " options on my page/project as some forums suggest.
(Please see attached picture of my gitlab page to see what I see)
Please note : when I click on my projects I get "404 Page not found" but the activity log shows that I have pushed files.
Thank you
I depends on the version of GitLab you are using.
Issue 9890 mentions:
When you want to remove a project in its settings (/<owner>/<project>/edit) and confirm the pop-up (where you have to enter the project's name), the project is deleted..
But you're not redirected to a different site automatically. Since the project is gone, the current site /<owner>/<project>/edit does not exist anymore so you're getting a 404.
This was fixed in 8.2.3 (commit 2497d3d)
You can delete those projects from admin area.
Login with the admin account
Go to Admin area (the wrench icon on the top right corner)
Click on Projects on the left side bar
There is a list of your projects, then just delete what you want.
(I am using GitLab 8.2.1)
I realized I wasn't enrolled as admin . That is why I wasn't seeing the gear tool to modify my projects.
Thank you Van and Issue 9890 for your response.
I am developing publishing site. I have some layouts that are pre-populated with web parts and have a problem when I need to make some change on the layout.
Deployment succeeds but I still see old version. If make I change in SP Designer it is reflected OK but not if the change is done by the feature that is being deployed.
It looks like after I deploy particular layout any site collection in that web application will have the first version.
I have tried deleting complete site, all the pages, layouts and nothing happens, after deployment I still see old layout.
Current solution for this problem was that I take new virtual image and start with clean machine.
Real problem is how to solve this on clients installation without reverting to clean machine. There will be some bug fixes and I will have to send new WSP file with some changes in layout.
Is there any way to force SharePoint to use newly deployed layout and not some old Unghosted version?
If the layouts are without web parts I don't have this problem.
Update
I am using default "Publishing Portal" and deploying layouts using features. For development I am using VSeWSS 1.3.
tried in SharePoint designer to detach page from layout and attach it again but still no results.
Since you are using VSeWSS, you can execute your own code upon feature activation. So try writing an SPFeatureReceiver that will call SPWeb.RevertAllDocumentContentStreams() to reghost directly after feature activation on the web(s) in question.
If this doesn't work, then the problem isn't about ghosting, maybe it's about Orphans then. But try this first.
If it's a feature that you are deploying you have do deactivate the feature and activate it after deployment again. And don't forget to do an IISRESET or an AppPool recycle.
If your new site collection has the first version of the layout make sure that it is really your new feature version that you are activating.
Try to reject your solution first and add the new one after that.
Are you using Site Definitons or Site Templates? If you are using either of these it may not update after initial provisioning.
Try completely retracting and deleting the solution from central admin, resetting AppPools and then redeploying the solution.
Make sure your element manifest for your feature specifies that existing files should be overwritten.
Looks like some folks have had problems with layouts too...
See http://msdn.microsoft.com/en-us/library/ms459213.aspx
If you are developing new sitedefinition, you can attach your new layout in the onet.xml file by using the property, i hope it will help you
-->