Comments/Ratings for a Single Item
I also meant to mention that I disabled the code for adding the vertical box that displays the table of contents and other info. When the early sections are short, this makes the page look bad by pushing down the start of the next section. It can also get in the way, and the information it displays is either elsewhere or not that critical. Most of the time, it is easy enough to page down to see what's on the page, and most pages aren't so long that relative links to page sections are of much help.
Hello, I would like to know how long can take the review process. I've made a submission one week ago and I see nothing happening. Maybe it's the normal delay, or maybe I did something wrong. Having no feedback at all, it is difficult to know. Thanks to all reviewers.
I'm not seeing it. I'm not sure if you did anything wrong or if the script for displaying submissions needs updating. What is the title or URL of your submission?
The title is Zanzibar-XL:
https://www.chessvariants.com/rules/zanzibar-xl
It appears in my "unreviewed submissions".
Since I posted it, I have re-drawn the graphics with the Chess Board Painting Tool of Musketeer Chess. I didn't know if I could update my page, I was afraid to add more delay if I do it.
I also tried to make :
https://www.chessvariants.com/play/zanzibar-xl
This one too is in my "unreviewed submissions". But I stopped writing this one because I was not sure to understand if I need to do both.
Sorry if I did something wrong, probably I missed a point somewhere. Thank you for your help
I am replacing the notion of a contributor account with direct counts of someone's published and unpublished submissions. These will be used to limit how many new submissions someone can submit before the editors review and publish them. Those with no published submissions will be limited to 3 unpublished submissions. Those with one published submission will be limited to 4. Those with 2 to 8 published submissions will be limited to 6. And those with 9 or more published submissions will be limited to 9 unpublished submissions at a time.
One reason for this limitation is to replace the 1MB limitation on daily uploads. I am replacing the upload scripts with a new file manager. An early version is already in the editing links. It isn't complete yet, but it already allows both uploading and deletion of files, and it displays images with data about the images. The current version should be stable, and I will continue working on it under a different file name, so that I don't disrupt anything for users. Anyway, the new file manager works by allowing you to upload no more than 2MB of files for a given submission. Without the 1MB daily restriction, someone could upload a lot by creating multiple submissions, but limiting the number of unprocessed submissions puts a stop to this.
If it turns out that contributors really need more than 2MB per submission, adjustments can be made later.
The new file manager for members is now available. It will let you
- Upload files
- Delete files
- Reduce the size of graphic images
- Restore backups after reducing graphic image sizes
- Sort alphabetically, newest first, oldest first, largest first, and smallest first
- Let you filter the files displayed with a wildcard pattern
Because this file manager is for members in general and not for the editors in particular, it lacks some features that a regular file manager would have. It will not allow the uploading of server-side scripts, the creation of new files, the free renaming of files, or access to directories not reserved for your submission.
I am reworking how image reduction works, because the way it presently works, caching of the original images can cause you to see the wrong image and think that the reduction looks better than it actually does. The way it will work after I finish debugging the new version is that each reduced image will get a different name reflecting how it was reduced in size. This will allow you to see the image accurately. I'm stopping for tonight, because it's late, but I'll continue working on it tomorrow.
... caching of the original images can cause you to see the wrong image ...
Indeed, I also have this problem after uploading an image to replace one that was accidentally uploaded under a wrong name. It keeps displaying the old image. As a consequence it now displays a Go Between for the black Golden Bird, and and White Elephants for the Western Barbarians, in the 1-kanji tile set for Dai Dai Shogi.
The new version of the new file manager is now up. Instead of reusing the original filename for reduced files, it saves each reduced file under its own name. This lets you see it correctly instead of seeing a cached version of the original image. Instead of restoring backups, you may choose to delete the new files. Instead of choosing to delete backups, you can choose to keep the new files. This will replace the original files with the new files and delete any other reduced versions of the same image. Since I don't know how to automatically purge a file from Cloudflare's cache, it will look like the original file for a while. For reduced files, this is not a big deal. If you redraw an image and use the same name as an old one, that's a bigger problem, but it goes beyond what the file manager let's you do on its own.
It keeps displaying the old image. As a consequence it now displays a Go Between for the black Golden Bird, and and White Elephants for the Western Barbarians, in the 1-kanji tile set for Dai Dai Shogi.
Fergus, do the images get refreshed eventually or will it stay this way unless you manually clear the caching?
The cache lasts for three days before it is automatically cleared.
@Fergus: Would it be easy for you to have the upload manager also accept archives (e.g. .zip or .tar.gz), and unpack those in the upload directory for the article? It is really very tedious now to upload a large set of piece images one by one.
I'll see what can be done, but I can't let archives unpack indiscriminately, because that would allow hackers to upload server-side scripts.
... I can't let archives unpack indiscriminately, because that would allow hackers to upload server-side scripts.
Indeed, that is a worry. Is the server configured to execute scripts anywhere, or just in some designated directories? It should still be made impossible to unpack anywhere outside the directory intended for the article. But I suppose that archiving commands to extract files can be called in a way that they ignore directory structure, and save everything in the current directory.
Savest would probaby be to extract everything to a temporary directory not accessible through the net, and then only copy files with some allowed extensions to the target directory, and delete what is left over.
I have added the ability to upload multiple files at once. You can now use the file requester to select multiple files instead of just one. For each file, it will check the extension, and it will check its filesize against the remaining available space. If it is an allowed file type, and uploading it will not exceed the 2MB quota, it will attempt to upload it.
I probably won't implement the unpacking of archives, because uploading multiple files at once makes uploading easier enough without it, and unpacking archives runs the risk of letting people upload more than 2MB.
This worked like a charm, thanks! Indeed no need for archives. I uploaded the entire set of 2-kanji tiles for the large Shogi variants to the Maka Dai Dai Shogi graphics directory in a flash.
I did detect an irregularity, though: the directory to which I now uploaded (/membergraphics/MSmakadaidaishogi) was initially empty. Which surprised me, because I did have two images in the article. On closer inspection, it turned out that these images are in /membergraphics/MSmakadaidaishog , i.e. without the final 'i'. Apparently the old upload script had clipped the filename. So these old image files are now outside my grasp to manage. (Not that there is any need for that now, but I still wanted to report it.)
ItemIDs used to be limited to 16 characters. After changing that, I created a table with old ItemIDs and the new ones they correspond to. According to that table, MSmakadaidaishog is the old ItemID for MSmaka-dai-dai-shogi, but for some reason, it is using MSmakadaidaishogi for the directory name.
The code for allowing the use of alternate pre-existing directory names was removing hyphens from the names of new directories. I corrected it to not do that any longer.
Ummm... It did not work as well as I thought. Now that I pointed the Interactive Diagram for Maka Dai Dai Shogi to its own graphics directory, rather than to my own website, only 20 piece types show up. Turns out the MSmakadaidaishogi directory indeed only contains 20 PNG files. The remaining tile images (of 312) were not uploaded.
Perhaps I am using it wrong? What I did was click 'Browse' in the upload manager, sype Ctrl-A in the file-browse dialog's main window to select all files, press "Open" in that dialog (so it closes), and finally press "Upload" in the upload manager. (Using FireFox on a Windows PC.)
PHP has max_file_uploads set to 20, and even though I've tried changing this in php.ini, it hasn't made a difference. I made sure it was the correct php.ini file. I stopped and restarted apache. And I even set a value for suhosin.upload.max_uploads, which I found a recommendation to do. But when I run phpinfo(), it still reports that max_file_uploads is 20, and that's all it lets me upload at one time.
H.G., Since you're probably the only one who needs to upload huge numbers of graphics, it may be easier for me to manually unpack an archive for you after you upload it. Just let me know where it is and what it's called.
OK, too bad. But you are right, the large Shogi variants are a bit extreme in every way, and we probably won't encounter many other cases. It would indeed help me a lot if you could unpack the archive in MSmakadaidaishogi, even with 20 at the time it would be a lot of work to get them all there.
The archive is at http://hgm.nubati.net/2kanji.tar.gz .
Thanks!
where am i supposed the alert that my chess varaint is ready in here, or where, cuz it said that im supposed to alert you guys
25 comments displayed
Permalink to the exact comments currently displayed.
I want to note some changes in how user-submitted pages are displayed. Instead of relying on the value of the UsesHTML column, it will check whether the text to display contains any HTML tags. It does this by stripping the HTML tags from a string and comparing the result with the original string. If they are the same, it doesn't contain any HTML.
The absence of HTML was previously handled by wordwrapping the text and putting PRE tags around it. But it is now handled by placing each separate line inside of a P tag. If you mean to use ASCII art on a page, you should add the PRE tags yourself.
If you use CKEditor's WYSIWYG mode, it will automatically add HTML code to your text. If you use Source mode, you will need to enter any HTML yourself. If you do not enter any HTML, then write each paragraph as a single unbroken line, and put an empty line between each paragraph.