If I go to Filelist in the Typo3 backend and check the option to display thumbnails, I only see broken image links.
Yet I remember that the thumbnails displayed ok at some point.
A test of ImageMagick in the install tool of typo shows, that ImageMagick is working ok.
What to do?
It's not only RealURL's problem - although it's most common while users are manipulating this file manually to add custom rules. Anyway this problem also ocures with typo3conf/localconf.php.
How to confirm:
Right click on the broken image and choose Open image in new window it will open a file with address like: http://somedomain.tld/typo3/thumbs.php?&file=..%2Fuploads%2...etc use some browser to preview the source code ie. in Chrome prepend the address with view-source: like: view-source:http://somedomain.tld/typo3/thumbs.php?&file=...etc. There should not be any whitespaces before the code of image...
How to prevent?
As you wrote. Check your config files like realurl_conf.php or localconf.php and make sure that there are no spaces before <?php. In case of script ending.... just remove the ?> tag, so script will end automatically without white spaces (even if you'll add 100 empty lines after last line of code), unfortunately sometimes finding this one annoying space in configs takes hours, so....
How to fix permanently?
I'm surprised, that isn't fixed after all these years still, while it's quite easy with ob_end_clean(), edit file: t3lib/thumbs.php, at the beginning (ie. right after php tag) add line:
<?php
ob_start();
Next find main() method, add at its begining line for cleaning output buffer, which will remove all garbage included from other files:
function main() {
ob_end_clean(); //here
...
Voila!
After Plesk update on one of servers by client's sysadmin we get an empty file /tmp/.tmp.err which was autoprepended with auto_prepend_file in php configuration.
So, all TYPO3 PHP scripts were prepended with an empty string. All dynamic thumbnails and dynamically generated XMLs were broken. Some unique situation, but probably could help to somebody.
In our case an old version of the extension 'spamshield' cause the same error.
We had Typo3 4.7.15 and 'spamshield' 1.0.2.
Please check server error logs for entries like:
PHP Warning: require_once(PATH_tslibclass.tslib_pibase.php): failed to open stream: No such file or directory in /typo3conf/ext/wt_spamshield/Classes/Extensions/class.tx_wtspamshield_extensions_abstract.php on line 25, referer: http://domain.tld/typo3/sysext/cms/layout/db_layout.php?id=16
[Tue Sep 17 09:46:13 2013] [error] [client 92.203.10.178] PHP Fatal error: require_once(): Failed opening required 'PATH_tslibclass.tslib_pibase.php' (include_path='/typo3/contrib/pear/:.:/usr/local/php-5.3/lib/php') in /typo3conf/ext/wt_spamshield/Classes/Extensions/class.tx_wtspamshield_extensions_abstract.php on line 25, referer: http://domain.tld/typo3/sysext/cms/layout/db_layout.php?id=16
Updating 'spamshield' to 1.1.0 fixed it.
There is a good chance that you may have the extension
rearUrl
installed.
Please check the realUrl config.
Typically this is located in
typoroot/typo3conf/
and is named realurlconf.php, realurl_conf.php or realurl_autoconf.php
Make sure there is no comment or whitespace lines before the <?php tag, as well as none after the closing php tag at the end.
Clear typo caches, then it works again.
Related
I don't really know if this would be a good place to ask this question, but FileMaker's forums haven't really been all that helpful. Our graphics department recently has been having issues with a script that they have been using for a few years now, and it just stopped working. I know nothing about FileMaker's language and have never used it before, I've just been asked to try and get it figured out.
The version that we are using is Advanced Pro 18.
Here is a snapshot of the script that is being run
This is the error it produces:
Any help would be appreciated, Thanks!
Check, if there is any font used in layout is missing in their computer.
If there are any fonts with upper case extension (.TTF), change it to lower case (.ttf)
It it is not the case, try Arial font for all the fields in the layout.
Make sure you have enough space.
Make sure your pdf document with the same name is not open.
Reinstall your pdf reader.
Suggestion: You can make the script step more simple.
You should use full file path to set the $Filename variable in line 7 and line 18, like these:
in Windows:
Set Variable [$Filename; Value: "filewin:/DriveLetter:/DirectoryName/" & Log Book::calculate job # & ".pdf"]
or in Mac:
Set Variable [$Filename; Value: "filemac:/VolumeName/DirectoryName/" & Log Book::calculate job # & ".pdf"]
One late additional note: make sure the filename is free of "prohibited" characters. If the string produced by Log Book::calculate job # included a "/" character, for example, you'd likely see the same error message.
I'm getting 4 errors for malformed JSON and one command compileSwift failed with a nonzero exit code error.
I have no clue how to debug this since it doesn't list what file this is occurring in.
I have tried deleting the workspace and pods directory and doing a new pod install && pod update.
I have tried deleting the derived data.
Neither have worked.
I was getting the same error and after reading above comments i went through my code and saw this "return 93à"
So after removing this "à" it's working fine now.
So here is my story on the exact same issue but a totally different cause and resolution.
TL;DR - Decode that problematic array as a string and read it, that is your real issue, not the one with JSON.
And here is my full story ...
First things first ... I got to this error by moving my app files to a framework project and changing their target.
I tried all you guys suggested, but with no luck, it just took me some time to find out how to report those files recursively. If anyone wants to check their encoding in the whole project, here is how to do that:
find . -type f -name "*.swift" -exec file {} +
All my files reported either ASCII and UTF-8, I even removed all Unicode characters to make them all ASCII, and it still didn't help.
Anyway, totally desperate, I decided on the last attempt ... trying to decode whatever was in that undecodable sequence of bytes.
I opened up my browser console, and did this:
String.fromCharCode(...[123, 10, 32, 32, 34, <the rest of the error array from XCode>])
And it saved my day, giving away the actual problem information.
What I got was the actual error message that for some reason (still unknown to me) the compiler wasn't able to process.
Here is a short extract from which you can also see why all people see the same sequence at the beginning:
{
"kind": "finished",
"name": "compile",
"pid": 27181,
"output": ...
... /RecognizedSymbolBlock.swift:5:15: error: use of undeclared type 'CGRect'\n let rect: CGRect;\n ...
... /RecognizedTextBlock.swift:3:7: error: type 'RecognizedTextBlock' does not conform to protocol 'Decodable'\nclass RecognizedTextBlock ...
So it turned out my problem was not having CoreGraphics framework included in the target, as well as not having it added with import CoreGraphics in the file itself.
Strangely enough, when I looked at that file in XCode (which I didn't do before as it was all just move of a code that worked before), I suddenly got all these errors displayed clearly.
My last weird finding was after I asked myself ... "Why the hell did it work in the original target without the import CoreGraphics?"
It turned out that having this in the bridging header file automatically brought it linked frameworks with it as if they were imported in all my files (it is one of the linked frameworks I use which is using UIKit):
#import <TesseractOCR/TesseractOCR.h>
But it can be anything, really, like:
#import <UIKit/UIKit.h>
The point is if you are using the bridging header file, it may easily hide the fact that you are not being forced to write consistent code with all necessary imports.
Anyway, my primary goal is to let everyone know that their original problem is most probably something totally different and the original issue is actually encoded in that error byte array everyone is getting. Even if you face encoding problems, this byte array may tell you what is wrong with your code.
Happy fixing!
In the navigator pane, the reports tab (last one) is your go-to for these situations. You can see detailed logs of build actions and can track down from there.
I had the same errors from the question. I dragged a file from project_1 to project_2 and all of a sudden all those errors appeared inside project_2. The odd thing was the new file that I dragged in had nothing to do with the errors because they appeared in completely different files that I had previously dragged in from project_1. Those files worked fine for months and the errors didn’t appear until after I dragged in the new file.
I closed Xcode, opened it back up, and the beachball of death started spinning. Xcode was basically frozen, I had to wait about 45 minutes for it to unfreeze.
I added screenshots of the errors and steps of what I had to do to resolve this issue.
1- These were the original errors, just like the ones from the op's question. I had 151 errors:
2- After the beachball stopped spinning I started to look through all of my files. I ran into a file that was somehow corrupted and its normal code was somehow replaced with the odd code inside the middle/right pane below.
Copying and Pasting the corrupted code from the middle/right pane didn't work at all which was odd but I did a global search (cmmnd+4) for "bookmark" and 6 more files appeared that also contained the corrupted code (shown inside the left navigation pane).
"bookmark" is the first word on line 1 inside the file in the middle/right pane, that's why I choose it:
3- I c+p the 6 files from the original project back into this project (the corrupted one) and the errors went from 151 to 10 new errors. All 10 errors were Invalid UTF-8 found in source file:
4- I looked inside all 6 files and inside the commented out code at the very top of the file there was a strange symbol in place of the copyright symbol on line 6:
5- I deleted the strange symbol and everything worked again.
I don't know how those files were corrupted. I think it has something to do with dragging them in from one project to another. Probably was just a random bug. To be safe I deleted the 6 files then added them back in one by one by actually creating a fresh file inside project_2’s Xcode. Then I c+p the code from same file from project_1 back to project_2. No more dragging Swift files from project to project for me.
Very strange.
In my case this compile error was thrown because of source code encode/decode issue. Try to close Xcode and programs which work with a code simultaneously and restart Xcode
I hit the exact same error message converting a workspace from Swift 4.2 to Swift 5. Even with the same numeric sequence in the error message.
The swiftc command was dying on some unicode characters in my source file (in the copyright boilerplate at the top of my file). As suggested by t0rst, you can use the inspector to see which file the command died on.
After removing the unicode characters, the build worked. I suspect there may be some issues with the update to use UTF-8 as the default storage class.
EDIT - Just discovered that the Unicode storage on the offending file was indeed wrong. In the terminal, run file *.swift on your source files. Files with 'UTF-8 Unicode text' are fine. The file that was a problem reported as 'ISO-8859 text'. Use iconv -t UTF-8 src dst to fix the file.
In my case, I had accidentally added a shortcut to a swift file, rather than the swift file itself.
To decode the above code. Right click on browser page, click on inspect and open console tab. In console tab String.fromCharCode(123, 10, 32,23) replace with your numbers and hit enter. You will receive the exact problem in readable format.
I’m using Doxygen 1.8.10 (on Windows) to generate LaTeX files, and MiKTex 2.9 to generate a PDF. The PDF is functional, but not very pretty. I’ve figured out how to customize the title page (I added graphics and non-default text) and how to get the images into the PDF.
But... how do I change the styling for things such as the color of URLs (which are just text in the Doxygen comments, and then Doxygen turns them into \href items)?
**** I believe I need to change something in the hyperref package’s config or what Doxygen writes to the .tex files, but I’m not sure which approach is right, nor how to do either one...
I’ve created a custom_doxygen.sty file, and assigned it to the LATEX_EXTRA_STYLESHEET. I assume that it’s being picked up by Doxygen because Doxygen is successfully picking up my custom LATEX_HEADER file, which is in the same directory as the custom_doxygen.sty file. But what I don’t know is what to put into the custom_doxygen.sty file?
If I run everything as default (that is, no LATEX_EXTRA_STYLESHEET), the following code gets written to the refman.tex file:
% Hyperlinks (required, but should be loaded last)
\usepackage{ifpdf}
\ifpdf
\usepackage[pdftex,pagebackref=true]{hyperref}
\else
\usepackage[ps2pdf,pagebackref=true]{hyperref}
\fi
\hypersetup{%
colorlinks=true,%
linkcolor=blue,%
citecolor=blue,%
unicode%
}
And what I need is for the “urlcolor” to also be blue (its default in the hyperref package is magenta—an odd choice for sure).
I tried just basically copying what was in the refman.tex file to the custom_doxygen.sty file (and making sure that the custom_doxygen.sty file is assigned to the LATEX_EXTRA_STYLESHEET setting in my Doxyfile) and adding a “urlcolor=blue,%” to the setup section, but there’s no change in the output.
If I manually edit the refman.tex file (that is, I add "citecolor=blue,%" to the \hypersetup) after it's output from Doxygen, and then use the edited file as input to MiKTeX, I get the desired output.
So a workaround could be to just script the desired change and run the script every time. But it would be certainly be better to get Doxygen to write the necessary configuration. Plus, there are other things I want to customize (such as the font of explicit html hrefs), so I'd like to learn how to do things properly.
WCAT from Microsoft is as simple as it promises to be. Running it on Windows 7 x64 is not that straight forward though. The included script file breaks and the XML transformation for the output summary also uses MS-only features.
You can still look at a formatted version of the log.xml using Internet Explorer 9, hitting F12 for the developer features and enable Browser Mode:"Compatibility View". This will allow the xsl transformation, which will not work anywhere else, as other browser complain about some invalid functions and syntax.
If you have Visual Studio installed, you can also use it to apply the XSLT.
In Visual Studio 2012:
Ensure that the XML file that WCAT created (log.xml) and the XSLT file (report.xsl) are in the same directory.
Open the XML file.
In VS2012, click on the XML menu > Start XSLT Debugging (or Start XSLT Without Debugging).
Wait a few seconds for the result html file to be generated.
As an aside...
Remember that the1 WCAT 6.3 report.xsl file has some bugs/typos in it.
The report.xsl causes the the following errors when you transform with it:
Variable 'i' has not been declared (line: 52, column: 13)
The variable or parameter 'rowId' is either not defined or it is out of scope. (line: 1182, column: 37)
The variable or par
You can fix this manually (reference):
Cut the code on lines 1151-1157 and paste it on line 1146.
On line 51 add: var i=0;
Solution for WCAT 6.4.0:
Cut the code on lines 1259-1265 and paste it on line 1293
On line 53 add: var i=0
Valid report.xsl:
https://www.dropbox.com/s/avyuyc6bxzt5k6x/report.xsl?dl=0
I had the same issue, after which i went through the xsl file and fixed the code.
Unfortunatelly IE was still not displaying it correctly, however in Inspect Element the DOM seems to appear fine. So you need to save that into a HTML file and it should look fine after that.
I use WCAT frequently and found that opening the log.xml file in IETester is reliable as you can select the IE8 rendering engine to consistently view the formatted report. No need to edit the xsl or find another viewer after IE upgrades.
i have opened result.xsl in studio, start debugging, defined the 'result'.xml as input and start debugging.
you will get 3 errors. all simple to fix.
1) add a 'var' before the i in a loop
2) remove the $ in the two other error lines
works after that change
My Localizable.strings file has somehow been corrupted and I don't know how to restore it.
If I open it as a Plain Text File it starts with weird characters that I can't copy here.
If I leave the file be the app builds. If I make any changes either the values aren't interpreted properly or I get an error at compile time.
Localizable.strings: Conversion of string failed. The string is empty.
Command /Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/copystrings failed with exit code 1
I suspect this is an encoding problem but I don't know how it happened (maybe SVN is to blame?) nor how to solve it. Any tips will be much more appreciated.
I have issues with the same file that sound very similar to your own. What happens for me is that Xcode doesn't know the correct file formating. I often get this when rearranging the project and I remove and re-add this file to the Xcode project. When I re-add the file, its encoding gets set to something like Western Roman which can't seem to render anything other than ASCII.
Here's what I do to fix the problem:
In Xcode select the Localizable.stings file in the Groups&Files panel.
Do a Get Info on that file.
On the info panel select the General tab.
In that tab go to the File Encoding and change its value.
The last step is where the trick lies as you now have to guess the right encoding. I find that for most European languages that "Unicode (UTF-8)" works. And for Asian languages I find that "Unicode (UTF-16/32)" are the ones to try.
I just had that error because I forgot a semicolon. Took me a while to figure it out. Seems like a really ambiguous compiler error but the fix was simple.
Make sure in File-Get Info, that UTF-16 is selected. If it's set to none or UTF-8 as encoding then you need to change it. If your characters have spaces between them then you choose to "re-interpret" the file as UTF-16. If there are weird characters in the file, then you need to remove them.
Execpt the UTF-8 problem, sometimes you still have to check the content in case if there are some syntax problems.
Use the following Regular Expression to verify your text line by line, if there's any line not matched, there must be a problem.
"(.+?)"="(.+?)";
You can use the plutil command line tool. Without options or with the -lint option, it checks the syntax of the file given as argument. It will tell you more precisely where the error is.
This happens to me when there is a missing quote or something not right with the file. MOst commonly, since my language files are done by another team member, he tends to forget a quote or something. Usually XCode shows an error on that line, sometimes it does'nt and just throws "Corrupted data" error.
Double check if all your strings are properly closed in quotes
Open the file in Xcode.
Right click it in Project Navigator.
Select Open as -> ASCII Property List