The structure of the family directories, as outlined in the docs requires every image to be placed inside the images directory. However, the OptaPlanner documentation contains both images and asciidoc files in the same directory per chapter. Please see the directory structure below:
https://github.com/kiegroup/optaplanner/tree/main/optaplanner-docs/src/main/asciidoc
Changing the current structure is undesired due to existing references from external repositories (breaking backward compatibility).
Is there a way of configuring Antora to pick up images from the pages directory and its subdirectories?
No.
The best-practices answer: Antora requires a specific directory structure and you have to adopt it.
You can adjust the Asciidoc markup to achieve this goal:
image::./relative/path/to/image.jpg[]
However, doing so could break your compatibility.
Antora 3 (currently in alpha) will provide symlink support, so you could create symlinks in the images folder that point to the images within the pages folder. Once that is in place, you can refer to those images like any other image in the images folder.
With Antora 3, you also could write an extension that locates images within the pages folder and add them to the contentCatalog as if they had been in the images folder. That would be notably more effort.
Related
I am building an internal project wiki for a group software development project. The project wiki is currently powered by VimWiki and I send the HTML files to both the project supervisor and each of the development team on a weekly basis. This keeps our Intellectual property secure and internal, but also organized and up to date. I would like to put diagram images into the wiki itself so that all diagrams and documentation can be accessed together with ease. I am however having trouble making the images transferable between systems. Does vimwiki give a way for image files to be embedded such that they can be transferred between systems? Ideally the solution would make it possible to transfer the output directory of the Vimwiki as a singular entity containing the HTML files and the image files.
I have tried reading the documentation on images in the vimwiki reference document. I have not had luck using local: or file: variants. The wiki reference states that local should convert the image links to a localized location based on the output directory of the HTML files, but it breaks my image when I use it.
I have currently in my file
{{file:/images/picture.png}}
I expect the system to be able to transfer the file between computers but it registers to an absolute link and also does not include the image directory in the output directory of the vimwikiAll2HTML command.
I know this is an old question, but try to use {{local:/images/picture.png}} instead. If you open :help vimwiki in Vim, you can find a part that says:
In Vim, "file:" and "local:" behave the same, i.e. you can use them with both
relative and absolute links. When converted to HTML, however, "file:" links
will become absolute links, while "local:" links become relative to the HTML
output directory. The latter can be useful if you copy your HTML files to
another computer.
I found all of these answers to a question I had:
Store pictures as files or in the database for a web app?
Storing images in SQL Server?
To Do or Not to Do: Store Images in a Database
And the last one links to even more versions of the same question. They typically have the same answer, suggesting to use a file system, then store the address in a data base. When they say "file system", do they mean store it in the folders that you use to make the website?
The way I've been learning to make websites, there's the "views" folder that has all the layouts, then there's the "public" folder that stores your css and js files. Then I have a line of code in the app so I don't have to type public all the time when I'm linking to my css files or js files. So would I store the images in there? With it's own folder and maybe a folder for each user? What happens when there's a lot of users and a lot of pictures?
Or should the pictures go somewhere else entirely?
I've done my best to find the answer on my own, but "file system" is such a generic term, I can't find the specific answer.
Yes, filesystem means to put them as files alongside the files that your website consists of.
Generally, there are a couple good practices to follow when doing so:
Put them in some folder that's dedicated to user data, not to the same folder you put your website's core files
Generate artificial file names (UUIDs or database-generated IDs) for them instead of using the original file names to avoid name collisions
If you expect a lot of files, on some filesystems it may be a good practice to create a level of subdirectories to limit number of items in each directory
It might be a good idea (depending on your use case) to forbid direct access to this folder with user data through plain HTML
Instead read the files and output them through your script
This is required if the files are not all public (if any authorization is needed to see them)
I'm looking for a simple tool that would allow users to update and tag assets.
THen search/browse for assets and view the assets in the search results.
I have lots of files, i.e. logos, buttons, infographics, icons. I'd like to be able to share the with co-workers and have them be able to easily locate them without have to guess based on file names.
Right now I'm using apache with dir listing and htaccess. But this is less than ideal.
Are you talking about Version Controls? If so, Git can help.
what is copy items into destination group's folder (if needed)
is this a good option? If I dont choose it will it just make a reference to my files?
Also if I have two images with the same name like /images/home.gif, /public/home.gif
but they are in different groups how does the compile know which image to use? is this even possible?
I'll have a crack at this :-)
1 & 2 - Used when adding files to a project. If selected, the file you are adding is copied into the projects directory from wherever it originally was. Note it is copied. If not selected, the project can still use it, it just has a reference to the original source file. Which means that if something happens to the original file, the project will not longer have a copy it can use. Personally for files such as images I copy them into the project so they stay with the project. For other things such as external apis, I don't because I don't want multiple copies everywhere.
3 - If you have two images with the same name you won't be able to copy them in without renaming one. XCode may do this for you, I've never tried. I'd suggest renaming one so you control it's name.
4 - Don't get confused by groups. They are logical groupings of files within XCode and do not refer to the underlying file system. Having said that you can actually assign a directory to a group so if you really wanted to you can match the two. I tend to do it a little. In my projects I generally have a src and test directory. I setup two groups and assign them to refer to these directories. Then when I create a new source code file I can create it in the src or test group and it will be created in the sub-directory instead of the project root directory. Often below src and test I will use other groups, but they do not map to any sub directories. The result is that the root directory of the project is free of source code files and the source code also has source and test code separated.
I am looking to clean up the file that we store in source control (SVN) for the Magento projects we are working on.
Which files/folder are have no purpose being in SVN, ie the ones are not necessary for the site to function, or are only transient?
So far I have identified
var\cache
var\session
media\temp
var\locks
downloader\pearlib\download
downloader\pearlib\cache
There are some I am unsure about:
var\report
downloader\pearlib\docs
media\catalog\product\cache\
Can anyone provide a definitive list?
http://activecodeline.com/git-ignore-gitignore-file-for-magento-project answers a larger question, but could be helpful none-the-less.
There's a whole bunch of stuff in Magento that doesn't need to be in source control, as it will remain constant (as long as you follow some sane development practices.) The above link goes through all the directories that need not be tracked by source control.
I typically ignore these folders for development, but you may choose to store images if you think it's appropriate:
/var: This is always temp data or data that can be regenerated
/media: These are images and uploads, not really source code, but keep if you want
/downloader: I don't like to use Magento Connect and prefer to install things manually. You can always get Magento Connect elsewhere, so no need to keep it in the repo.
/includes/src: This is compiled source code, you can regenerate if needed. Not really that usefull since we have SSD disks and APC.
We usually have something like:
/app/etc/local.xml
/downloader
/var
/media
Media usually contains images that are configured in admin, like product/category images, logos, CMS images, merged JS/CSS and import/export data I believe.
Some extensions also have files in media that should be versioned (ex. product feed templates)
There is also an htaccess file in var and media so you have to include those.