Comments/Ratings for a Single Item
OK, I see what you are doing: you just put an unbalanced closing tag for MAIN and ARTICLE in the submitted text, and this will locate part of that text (in this case the Design Wizard, which initially is hidden) behind those elements. The fact that the display script still adds another {/MAIN} and {/ARTICLE} behind the Wizard does not matter; these are simply ignored by the browser.
With the screen width I have (enough for adding the left ad side bar), this makes the "fineprint" end up partly behind the article text, and mostly in the left side bar below the ad, however. This is a bit ugly.
I did find a work-around for that, which is structuring the submitted text as:
{DIV class="middle"} {ASIDE class="leftcol"}ad image{/ASIDE} {ASIDE class="leftcol"}ad image{/ASIDE} {MAIN} {ARTICLE} ------------------------------------------ Normal article text {/ARTICLE} {/MAIN} {/DIV} {div style="display:none"} Design Wizard {/div} {DIV class="middle"} {MAIN} {ARTICLE} ------------------------------------------- {p}{hr}{div class="fineprint"}This 'user-submitted' page...{/div} {/ARTICLE} {/MAIN} {/DIV}where the part between the dashed lines is the submitted one, and that outside it what the retrieval script adds. On Firefox this has the desired effect: when the Wizard is hidden the fineprint displays normally below the article, with the same left margin, like it was in the same ARTICLE element. All tags are now balanced (after the retrieval script does it work, not in the submitted text).
Only caveat is that it is against HTML regulations to have multiple MAIN and ARTICLE elements.
Charles, I have finished debugging the scripts, and I have relisted you as the author of your page. I added a note at the end as a demonstration that the scripts are now working.
Charles, I have temporarily listed myself as the author of Commedia dell'Arte Chess to debug the scripts.
H. G., when you mentioned the PRE tags, that clued me in on what happened. It was treating it as a submission that doesn't use HTML. The problem was that there were some mismatched variable names between two scripts, which caused checking the box for using HTML to have no effect. So I fixed that and closed the ARTICLE and MAIN tags just before your wizard.
It is worse than ever. This time all I get is a blank page, when trying to edit index information not just on that page but on any page of mine.
All escape codes for the less-than sign seem to be gone again, so that HTML tags that should have appeared as literals in the text now again are interpreted as active HTML tags.
Whatever you did, can you please undo it?
I did it for you, and I noticed what seemed to be side effects. The text was going over the inner nav bar, and the wizard wasn't working. So I undid it, but the text continued to go over the nav bar, and the wizard still didn't work. So it didn't cause those effects, but they are something you want to fix. In general, closing the ARTICLE and MAIN tags is just a matter of inserting the HTML for closing these in your code. This will leave you with some unexpected tags for closing ARTICLE and MAIN further on in the document, but the page should still work. Unlike BODY, ARTICLE and MAIN are completely optional in HTML documents, and you are free to place code outside of them. It is just that headers and footers are set up here so that MAIN and ARTICLE get opened in the header and closed in the footer, which places the main content of a page between the two ARTICLE tags, which are inside the two MAIN tags.
I have not experimented with this, but the CSS file defines a float style for the side bars, suggesting that the text would drape around the ads, if it were not for the setting of the margin. So perhaps there isn't any need to hide the ASIDE elements, if I just want more space at the bottom, and an I just reduce the marginLeft and increase the maxWidth of the MAIN element.
If you need greater width only at the bottom of your document, you may be able to get it by closing the ARTICLE and MAIN tags before the code for your design wizard. Technically, the sidebars do not run all the way down the article. They are both closed in the HTML before MAIN and ARTICLE even appear. They only appear to go all the way down, because MAIN is given a width that fits it between the sidebars.
> I cannot figure out how to make the printout to use the full width of the page One of the best ways of dealing with bugs is to report them. I took a look at the print preview for some pages and found the content displayed in a narrow column. I have now fixed that.
You can print pictures in monochrome by telling your printer to print the whole page in monochrome. Just adjust your printer settings before printing.
You do not have to edit the CSS of user-submitted pages to remove stuff you don't like; you can do what I did instead. I don't like the narrower content or sidebar ads either, although I used Stylish to remove them from all pages (and force the content to use the full width of the window), and to remove script warnings, as well as to remove the "fineprint" area (used for editing the page) from printouts (this also means I now have to maintain my own stylesheets, although I can deal with this; furthermore my stylesheets won't affect anyone else since they are local to my computer). However, I cannot figure out how to make the printout to use the full width of the page, nor to convert pictures to monochrome on the printout (if you know how to do these things, please tell me). However, note that at least Firefox does have "responsive design mode" which allows to test it at various screen sizes, as well as rotation and touch events (I myself do not use it, although it can be useful to you if you do mobile and that stuff).
The main purpose of the sidebars is to make the content narrower, because this makes a page easier to read. It also helps contributors who are designing pages on desktops with wide-screen monitors to design them in a way that will work on mobile devices, for which extra width is not even an option. So, yes, they have to go all the way down, and they should not be hidden unless it is for a page that requires the extra width and is not intended to work on mobile devices. Using the space for advertising is a side benefit of having the extra screen space available.
Never mind, I managed to close the ad colums by accessing them by class (leftcol/rightcol) to hide them, and reset the float, marginLeft and maxWidth of the 'main' element. So the Design Wizard can now use full screen width again.
Fergus Duniho wrote on 2016-03-12 ... I just modified this by commenting out each line that applied reverse_htmlentities() to one of the page content strings, and it fixed your page.Indeed it did. I just had to remove the extra level of html escaping that the JavaScript outputted, and now the Design Wizard is working as well. (Before, the HTML code for the designed diagram it would show at the end showed an extralevel of escapes on the lt symbols starting the tags.)
The side bar for advertizements still has a rather adverse effect on the page, however. It runs over the entire height of the page, even though only the top 20% or so is filled with adds. So it just adds a lot of blank space, distorting the actual content by compressing it in the space that is left.
Is it really needed to make these side bars run along the entire article if there is no content to fill them anyway? I cannot imagine that I am the only one annoyed by part of my screen being wasted for blank space. E.g. the side bars could be put only beside the Introduction and Setup sections, so that the later sections can use the full width of the screen?
After the Design Wizard has run and displays its result, the article even starts to overlap the ads in the side bar. This might be a consequence of that the width actually changes by running the Design Wizard. Would it be possible to hide these side bars from the JavaScript of the Design Wizard when it needs more space (basically when the user activates it). E.g. by giving them an id so that their display attribute can be set to 'none'?
One more change is that spaces in a name are now converted to hyphens, and not underscores, when generating an itemid.
I also modified the database and membersubmission2.php to allow itemids as long as 64 characters. Since itemids are being used in URLs, the 16 character limit is making less intelligible URLs when games have long names. I may update existing itemids to use longer portions of the summary field, but that will take a script that does it systematically.
I just finished rewriting membersubmission.php and membersubmission2.php to use PDO methods instead of mysql functions. Please let me know how it works.
http://www.chessvariants.com/index/membersubmission2.php
What is the URL for the script that gives you this error message?
25 comments displayed
Permalink to the exact comments currently displayed.