importImages.php is not moving all the files into the correct subdirectory - mediawiki

We have a wiki that was brought back from the dead using a torrent image archive of 32gb+ (that's compressed).
We ran importImages. That created sub-directories, probably from the image paths of the wiki articles.
Well, we have a lot of images not loading correctly (white space).
Turns out the importImages did not move all the images into their correct subdirecotires.
When you look up the image, it will have the expected sub directory i.e. images/1/1a/hello.jpg
But, the actual file is still in images/hello.jpg.
If you try to reupload the image using the single file uploader, it gives you an overwrite warning, ignoring this warning corrects the image, and stores it in the right subdirectory. But we have 200k+ images, and you cannot overwrite images using uploadWizard.
Is there a way to fix this? A parameter we can run, or a way to set all image paths to use just .../images/?
We are using version 1.35.1

Perhaps, $wgHashedUploadDirectory or $wgLocalFileRepo is not set correctly on LocalSettings.php. If this is not the case, try to launch importImages.php with --overwrite option.

Related

Image not found when opening in browser

I have come into an issue where my webpage will not load a background image in any browser if I open it directly into the browser, but if I open it up via a live server addon for VS code it works entirely fine and loads everything correctly. I have videos attatched to the webpage which load entirely fine in both scenarios, and have come to a bit of a deadend...
file's to see if file pathing is incorrect
Where the image should be loaded
The html file calling the class
This is a guess at the moment but it might be, on the second image that you posted, that you have detailed ../../ twice. This is telling the path to back up by two folders then look for the assets folder.
Looking at your file layout. You have an index page then an assets folder which contains a videos folder which contains the image.
You shouldn't need to back up out of the folders using any itteration of ../ from where you index page is located. The correct path might simply be assets/videos/cover_image.jpg

Use image in Sphinx as clickable link

Problem:
I have a table of images that I'm using as an overview/introduction. I want the end-user to be able to click on the image and it link to the HTML page for that image's corresponding introductory information1.
The problem is I can't seem to get the linking part to work. The table of images shows up fine, but clicking on an image just takes me to a page not found screen (see image at bottom of post). I've spent about an hour on Google but haven't found a solution yet.
1each image has a corresponding .rst file with the info I want the end-user to see
Info:
Sphinx 1.8.5
Python 3.7.6 (MiniConda)
Building html pages from reStructuredText files
sphinx-build -b html source build
make clean html
make html
Nothing special has been done in my conf.py file, other than including the RTD theme
I'm guessing I will need to do something fancy in my conf.py file if doing what I want is possible at all
Adding the .rst files to the .. toc:: directive in introduction_file.rst didn't help
Here is the reST code I have so far:
the image directives are all inside a table; table omitted for brevity
I'm also confident that the 'image directives inside a table' thing is not the issue
.. filename is "introduction_file.rst"
.. image:: images/my_first_image.png
:scale: 100%
:alt: My First PNG Image
:align: center
:target: introduction_files/my_first_image_intro_file.rst
.. also didn't work:
.. :target: introduction_files/my_first_image_intro_file.html
File Structure:
Home.rst is the entry point for the HTML pages (i.e. it used to be called index.rst until I renamed it and refactored conf.py accordingly)
--build
...
-- source
|--Introduction/
|--introduction_file.rst
|--images/
|--my_first_image.png
|--my_second_image.png
...
|--introduction_files/
|--my_first_image_intro_file.rst
|--my_second_image_intro_file.rst
...
|--_static/
...
|--_templates/
...
|--conf.py
|--Home.rst
I'm not opposed to doing what I want in HTML/CSS, but if there is a way to do it in sphinx then I'd prefer to do it that way. I will end up editing the HTML code regardless, but the less editing the better; Sphinx is essentially a quick-start or template.
This image is what I see in my browser when I click on one of the images in my table-of-images. The URL bar in Chrome shows the correct path to the .rst file though, so I'm a bit confused.
I tried changing the :target: file extension to .html but that didn't work either
Edit: forgot to add the location of introduction_file.rst to the folder structure
Solution:
Mix up between the paths. I was linking to the file in the source directory, but needed to link to the file in the build directory. Had to navigate back to the root directory with a few '../' prefixes, then navigate to the .html information file in the build directory. In other words, this is what it ended up looking like:
.. filename is "introduction_file.rst"
.. image:: images/my_first_image.png
:scale: 100%
:alt: My First PNG Image
:align: center
:target: ../../../build/html/Introduction/introduction_files/my_first_image_intro_file.html
The target option's value must be either relative to introduction_file.rst (you don't provide its location so you'll have to figure that out), or absolute to the documentation root, i.e., /Introduction/introduction_files/my_first_image_intro_file.html.

cPanel not updating the css file

I have been getting this weird problem where, when I upload a new CSS file to the public_html folder in cPanel, it is not updating on the website.
Whats really weird about it was that I uploaded the entire website again. Every html file, every folder, everything. And when I checked the CSS file it was the updated version, but the browser was somehow reading the old one.
To fix this issue I had to change the name of the CSS file (in all of the html files too because without it they were still using the old one even tho it was nowhere in the folder) and re upload the whole website again.
So, am I missing something here? Is this supposed to happen? Or is this actually weird and shouldn't happen at all?
I've also run into this problem. It seems to be a caching issue. Trying this person's trick is how I narrowed it down to being a caching issue:
https://www.sitepoint.com/community/t/css-html-files-updating-on-cpanel-but-not-on-website/271683/5
Smells like cache to me.
If your recent changes are NOT there, then play a trick on the URL by changing the path a little. For example if the path was /themes/mytheme/assets/custom.css or whatever it is, change the version and do something like /themes/mythemes/assets/custom.css?v=1234567
By changing the URL in this way, it would bypass any kind of cache that would be looking for the previous URL. In other words, you should now see your correct CSS file.

Including images in a Genshi/Trac template

I am trying to include some images in a Genshi template for my Trac plugin, but it always shows only the alternative text because it cannot find the images.
I have the following (X)HTML code:
<div>
<img src="file://c:/path/to/image.png" alt="asdf" />
</div>
When I use this code with a simple html file and open it in the browser, the image is displayed correctly, which means that both the path and syntax are correct.
But when I insert the code snippet into a Genshi template and use it within Trac, the image cannot be found. However, when I look at the HTML source code in the web browser and copy the URLs into a new browser tab, it is again displayed correctly. This means that only the server cannot find the image.
The images are in a directory inside the python-egg file, and the path points directly to the directory created by Trac, which also contains my CSS and HTML files, both of which are loaded correctly. The images are correctly referenced in the setup script which creates the egg.
How do I have to reference images in (X)HTML documents when using them with a server?
Is there a special way to include images in Genshi documents? (I haven't found one.)
Thanks to the comment of RjOllos and this site I was able to fix it by trying all of the URL types. Although it says for a plugin to be /chrome/<pluginname>, it was actually just /chrome that worked. See the edit below! So the full URL is then <ip>:<port>/chrome/path/to/image.png.
EDIT: I discovered I actually used the /chrome/pluginname version, just that I did not use the name of my plugin as "pluginname". See my comment below. It seems like /chrome/pluginname should actually be /chrome/htdocsnameor something like that, in case you use a different name rather than the plugin name when implementing the ITemplateProvider. In my case I called it images, which was the same name as the folder. END OF EDIT
Another mistake I made was forgetting the initial slash (chrome/path/to/image.png), which caused Trac to assemble the URL to <ip>:<port>/<current page>/chrome/path/to/image.png.

Local post assets with Jekyll

I was wondering how other people are organising their assets for individual posts when using Jekyll. For example, if a post has an image, do you just dump it in a shared images folder? I don't really like the idea of doing this - it means that an image is completely separated from a post, when I think they should be paired.
I wrote a plugin to let me organise assets in subdirectories easily:
https://github.com/samrayner/jekyll-asset-path-plugin
{% asset_path my-image.png %}
in post 2013-01-01-post-title would output:
/assets/posts/post-title/my-image.png
in page my-first-page would output:
/assets/my-first-page/my-image.png
I prefer to think of images as stand alone assets that are included in zero or more pages. Most of the time, my images show up in a single page. There are times when I want to have them in multiple pages and in other cases I don't link an image at all. If your workflow is to put each image in a directory with a post, finding them starts to require a significant amount of searching and you have to come up with something different for images that don't belong to a specific post.
The approach I use is on the opposite side of the spectrum. I have a single image directory (served from "/images") and 100% of my images are housed there. Benefits of this are:
When I'm adding an image to a post it's easy to know what path to use. It's always:
/images/{image-name}
For example: http://alanwsmith.com/i/aws-20111017--0906-02. This makes it possible to write a plug-in so all you have to enter is the image name and the rest of the known path is filled out automatically.
With an application like Photo Mechanic, it's incredibly easy to browse the single directory locally and see every image. If I want to include an image on another page, this drastically reduces the time to find it.
There isn't a separate location/process if I want to send an image to someone without actually including it in a page (i.e. send them a direct link to the image file). I just throw the image in the standard directory and send the direct link.
If you want to get a little more advanced, keeping all your images in a single directory makes some nice tweaks possible as well. For example, even though the URLs for my images start with "/images", the images are actually stored in a directory outside of the ones jekyll uses. In my case, the top of my source tree looks like this:
./html
./source-files
./image-files
All of my images are stored in the "./image-files" directory. In my apache config, I've setup an alias so that the URL "/images" points to the "./image-files" directory. For example:
Alias /images /webroot/image-files
When I run jekyll, it process everything in "./source-files" and drops it in "./html". Because all of the images are outside those two directories, jekyll never sees/touches them. As your image library grows this will help speed things up and will prevent a tremendous amount of unnecessary file copying.
Another tweak I like in Apache is turning on:
Options +MultiViews
This lets you call your images without having to use the file extension (e.g. no '.jpg', '.png', etc...). You can see that in the example link I provided above. It doesn't really matter for performance. I just like the way it looks and it saves me from having to type the extension every time I'm calling an image.
MultiViews also makes it possible to replace an image of one format with another without having to recode anything else. For example, if you remove "some-image.gif" and replace it with "some-image.png", you wouldn't have to touch any HTML. It would still be served form "/images/some-image". Needing to make changes like that is probably exceedingly rare. I just think it's an interesting thing to be able to do.
Finally, you can make a single decision about allowing or disallowing your image directory to be browsed. Personally, I only want my images to show up where I place them. So, I've set the .htaccess file in my images directory to:
Options -Indexes
If you are going to be working on a site with many thousands or tens of thousands of pages and images, this might not scale. For a normal sized, personal site, I find that this approach makes maintaining images easier.
I have now managed to develop a Jekyll plugin that helps keep posts assets alongside the Markdown file:
https://nhoizey.github.io/jekyll-postfiles/
Just like you, I really hate having all images in one single shared folder.
Most, if not all, of my images are useful in one single post, and keeping them alongside the Markdown file is really better for posts management:
I can drop a new post as one single sub-folder of /_posts/ in one step, without having to put the Markdown at one place and the image(s) at another
When I want to edit the image(s) of an existing post, I don't have to find the right image in a huge /assets/ folder, it is located just near the Markdown file
In my Markdown, I can use the image file name directly, without any path
If I want to use any Markdown editor with live preview, it works, no need for a specific assets folder configuration
I tried to have this for my blog (example post here).
For responsive images, I used the Jekyll Picture Tag plugin, but I had to fork it, because the Pull Request to deal with such paths was not accepted.
Now that Jekyll 3 is there, I wish it could let us use images both in a post folder AND in the /assets/ one, looking for an image marked with ![alt](image-file-without-path.jpg) in both, in that order.
For JavaScript and CSS, you may want to consider an asset pipeline. You can get a good performance improvement through bundling and compression. I also use CoffeeScript and Sass, so I needed a preprocessor to convert my assets. I use Jekyll Asset Pipeline to manage this whole process automatically when I run the jekyll command.
For images/video, I recommend you develop a convention for naming folders in your project. I generally have an "assets" folder then subfolders with the date of each post that holds the images related to those posts. If you have multiple posts per day, you might consider including the name of the post.
This answer:
Does not use plugins (works with GitHub Pages)
Allows you to keep images directly next to their relevant posts
Allows you to edit using Typora locally and see the images WYSIWYG
Just name your folders like _posts/2020-10-10-My-Title/ and include files like index.md and hero.svg or other images.
Then set your permalink: key in _config.yaml to :path.
Caveats:
Your folder names must be sluggified
Your images must all be SVG