As in the title, after updating the Paw (presumably version 2) client to Paw 3 - none of my .paw files will open.
Using the menu, all of my old files are now greyed out. Whenever I 'force' Paw to open my file in some way, the error I receive is as follows:
The document "__.paw" could not be opened. The file isn't in the correct format.
The file might be corrupted, truncated, or in an unexpected format.
This appears to be the case with every single .paw file I've created.
How can I migrate my original paw files to the new client? I see no feature to do so and am now severely regretting my decision to try the new features.
Sorry you had this issue.
This has been fixed in the latest release 3.0.4 it was an issue with 10.10. Can you drop us an email to support#paw.cloud if this persists.
Check to make sure you do not have the old Paw app in your dock. I went through upgrade as well and didn't realize I still had the old PAWs in my application folder.
Related
I can add a folder to the workspace (which doesn't seem to do anything, as far as I can tell), but the "map to file system resource" option seems to have been removed, and I can no longer live-edit css files.
Is this a bug, or has the process for mapping css files been changed?
This talk (https://developers.google.com/web/updates/2017/10/devtools-release-notes) says that the new version uses "magic" to map remote files to local ones, but I can't seem to get it to work at all.
For reference, I'm trying to map a reddit css file to one on my own computer. It worked fine on a previous version of Chrome (basically I add the folder, and map the css file inside it, which has been renamed to have the same name as the remote one) but not on the new one (Chrome 63)
I've just fiddled around with a problem, where only some files got mapped to my local workspace.
Turned out that Google Chrome also checks and compares the last modified date of your files.
If the file on the server has a more recent date than your local copy, this file won't be mapped.
I deleted the Bootstrap file on the server side and uploaded my local copy, which has an older last modified date. Google Chrome instantly mapped the file to my local workspace.
Out of curiosity I ran touch bootstrap.min.js on my server to set the last modified date to today. This broke my file mapping again.
Chrome removed manually mapping to filesystem resources because of the new Workspaces 2.0 (See: https://developers.google.com/web/updates/2017/10/devtools-release-notes).
You should be able to drag and drop your folder into the sources tab and it'll link the files automagically.
However automatic mapping doesn't work in many situations and there is a Chrome bug to re-add manual mapping
I had the same problem so I downgraded to Chrome 62 (preferences, history, extensions and so on are preserved).
Download Chrome 62 from
https://www.slimjet.com/chrome/google-chrome-old-version.php .
On OS X trash /Applications/Google Chrome.
Switch off auto-update by setting "defaults write com.google.Keystone.Agent alwaysPromptForUpdates 1". Default is 0.
May be you have to set "defaults write com.google.Keystone.Agent checkInterval 0" too. Default is 18000.
Install Chrome 62 as usual.
After starting Chrome 62 open "About Google Chrome". Chrome is checking for updates, but will prompt you to confirm.
The "Map to File System Resource..." menu item is missing. There appears to be no way to map files. It is completely broken as far as I can tell.
For me, the problem turned out to be the presence of the copyright symbol © in the file headers (which affected just about every file). With this character in the files, devtool refused to map the files but with it removed, the files map fine.
I'm also using Chrome 63.0.3239.132 (Official Build) (64-bit) and as I wanted to use the DevTools Live-edit to edit some js files I saw that the option "Map to file system resource" is missing.
After some research I have found out that the Live-edit is perfectly working in Version 63, you just have to:
go to Sources and then FileSystem
add the folder with your code to the workspace
After that, a small little green point will be displayed near your files (it means the synchronization is ready) and the changes via DevTools can be persisted locally:
Thanks to others in this thread saying chrome is checking the modified date.
Adding this to .htaccess solved it for me
IndexOptions SuppressLastModified
Of course you would not want this to get into your production code as it could stop browser caching working.
I cleared the cache and it works now.
Previously, I opened my CSS file from my FTP client, then I dragged the containing folder into the Sources tab > Filesystem tab (without caring about any folder names nor structure, I just dragged the FTP clients containing folder into it).
The persistent mapping worked straight away, edits from the Chrome Dev Tools were saving on the server. After 30 minutes of fiddling and playing around, it just stopped working and the CSS resource got greyed out. The file icon with the green dot was not appearing anymore.
It didn't matter what I'd do, it would not work, but when I cleared my cache, it started to work again.
File mapping started working reliably for me once I turned on a devtools setting -- click the upper-right gear icon and check Preferences > Network > "Disable cache (while DevTools is open)"
As of today, with Chrome Version 63.0.3239.108 (Official Build) (64-bit):
The feature appears to be still broken, not working 'automagically' nor consistently with the previous behavior.
However, adding a folder that reflects the resource's URL as seen in the Network tab, make it work again. So if for instance, in the Network Navigator tab you have:
http://mylocal.site/wp-content/themes/mytheme/assets/sass/partials/_header.scss
You will just need to add the whole wp-content/ folder to the Filesystem tab to get the feature work again as expected.
Had the same problem, but when my source maps included sourcesContent, the file mappings were automatically made and I could live edit my scss. Apparently chrome uses the content to find the right file.
node-sass --source-map-contents
I found the following issue here in stackoverflow however cannot comment as yet. I have a similar issue and wonder if there is anyone out there that has solved it.
https://stackoverflow.com/questions/40917501/tfs-2015-web-portal-code-viewer-not-working#
I am encountering similar here. In house TFS 2015, can't view code in the web portal using Google Chrome however IE is fine. I, however, am not using HTTPS so may be experiencing something slightly different.
When I do try to view a file in Chrome, the window where the code listing should be is simply blank. I did note too that the button for creating a new build definition appears to be indicating a broken image link.
This has not always been an issue. Around 4 months ago I could get the code view fine in Chrome and, to my knowledge as I have no access to the servers, nothing has changed apart from Chrome updates.
I've tried getting to previous versions of Chrome to no avail, though I wouldn't know which version I was on when this did work.
Interestingly, I have one or two .MD files around and these display perfectly well. They are simple text files. However when saved with .TXT extension (or anything else I've tried), they do not show. Curious.
Update
As you will see from the screenshot below, when selection on a file has been made, in this case a .SQL file, where I would expect the view to populate nothing at all appears.
As for the F12, I do get 5 of these:
Failed to load resource: net::ERR_CONNECTION_REFUSED
plus associated paths of course. We use Webroot internally here which has recently dropped in a Chrome extension however even when Webroot is disabled in its entirety (including removal of extension) I get the same behaviour.
All other Chrome extensions have been removed too at varying times to try to give a clean browser.
I have no other pop up blockers, ad blockers, etc installed on the workstation.
Problem solved thanks to the F12 key suggestion.
After some grovelling I was granted domain admin privs to have a dig around everything. It turns out that TFS was installed on ServerA with a URL port of 8080, this I knew from the original install and obviously the path I follow to get to my TFS web interface. What had also been done subsequently, with no consultation of the Dev user group, was that a second TFS application tier had been installed on ServerB, the port here was 8088.
I had not noticed the difference in path initially, assuming it was Chrome or workstation related. Anyway, I altered the port on ServerB to 8080 and everything jumped into life. I should not have made assumptions and should have paid more attention to the path in the error!
It seems the second application tier was set up on a non-production environment to allow senior Dev users access to the TFS Management Console rather than allowing them access to the original app tier which was on a production box. Our IT Operations just forgot to tell anyone.
Try to update your chrome to latest version of (55.0.2883.87 m (64-bit)).
Also clear the cache of chrome. I have also encountered similar issues. The solution is clear cache and connect to the web portal use another ID, then connect back use the original ID. I have no idea which one solved the problem. You could try both.
This problem should only be an individual phenomenon, since TFS2015 has been released for a long time.
I have tried to embed an image on mediawiki that I have installed on my server. The images are in this folder /var/www/html/mywiki/images$.
Here is the screenshot of what I see when I save the page to view the image
When I try the upload option, this is the error message i get
[b5f5e4d3] 2016-10-25 12:30:15: Fatal exception of type "MWException"
Where could i be making the mistake?
From my experience with mediawiki, when you upload to the site it stores them in randomzed lettered/numbered folders... ie w/images/9/9d and you have no control over uploading them directly to the folder through your server. I haven't tried directly uploading them, I've always used the wiki itself to upload.
MediaWiki offers some extensions for bulk uploading here:
https://www.mediawiki.org/wiki/Category:Bulk_upload
And you can find them under Special categories once you've installed the Extension and updated your LocalSettings.php to allow them to run.
I personally use BatchUpload (https://www.mediawiki.org/wiki/Extension:SimpleBatchUpload) because I don't have a lot of files to upload at one time, and although it is marked as stable, it sometimes sticks... still better than uploading one at a time.
If you find an alternative way for mass uploading using FTP directly to the server, I would love to know... as I searched for that myself.
Good luck!
You should not upload images manually, but use Special:Upload page to upload image into Mediawiki. Error you've mentioned indicates that there is something wrong with your installation, so you should put $wgShowExceptionDetails = true; into LocalSettings.php to see more details about this error. There is a chance that your /images/ directory is not writable - check its permissions.
Xcode 4.5.2 Mountain Lion , Mac App
I follow the documentation precisely. The Help Folder and its subfolders are added to the projects /Resources folder and appears blue in color.
Folder References were added by xcode if necessary.
Whether I view the HTML file in Xcode or externally in a text editor, I see the new version of the file.
Inside the app, the Help pages all display, the anchors work, but the pages are older versions.
A particular file that is not being shown with the latest version is DgxFiles.html
It is located in the scheme below as ../pgs/DgxFiles.html.
When I access Help inside the app, I see an older version of the HTML file. It seems the old help files are cached somewhere.
App's Info.plist has
<key>CFBundleHelpBookFolder</key>
<string>HungryMeHelp</string>
<key>CFBundleHelpBookName</key>
<string>com.DrummingGrouse.HungryMe.help</string>
The Landing page,HungryMe.html has:
<meta name="AppleTitle" CONTENT="com.DrummingGrouse.HungryMe.help"/>
The folder I drag into the project is named: HungryMeHelp
The Help Folder structure is:
HungryMeHelp/
Contents/
Info.plist
Resources/
shrd/ <shared artwork>
English.lproj/
HungryMe.html <title page>
HungryMe.helpindex
pgs/ <the rest of the content pages>
sty/ <style sheets, generated list template>
scrpt/ <scripts>
I have:
0. Deleted /HungryMeHelp and re-added it.
1. Cleaned the project.
2. Reloaded Xcode
3. Rebooted Mac
Trash the following files in your Home > Library > Preferences folder
com.apple.help.plist
com.apple.helpui.plist
com.apple.helpviewer.plist
Trash the following folders in your Home > Library > Caches folder
com.apple.helpui folder
com.apple.helpdata
com.apple.helpd
com.apple.helpviewer
What am I missing?
Thanks for reading. Mark
I found answers to my Apple Help Viewer Cache questions here:
http://www.cocoabuilder.com/archive/cocoa/312037-updating-an-app-help.html
http://macergun.blogspot.com/2011/06/dealing-with-help-viewer-cache.html
I found the posting below at cocoabuilder.com
As a result, I deleted existing copies of the app from my system.
The Help System updated immediately thereafter!
On Dec 13, 2011, at 5:17 PM, Graham Cox wrote:
With each update of our app, we typically change the help book. We're finding that the system is very poor at recognising this and caches old versions of the help which causes new stuff we add to be unavailable. While I can manually trash the help caches and force an update, this isn't something we can ask or expect of our users.
Search the archives, and you will discover that you are likely experiencing a well-known issue that has been around for a very long time. It typically only affects the developer, not your users. It is especially annoying to the developer if another, older version of the application is still on your computer, in the Applications folder or perhaps in the form of earlier build products that are still sitting around, because then trashing the help caches and forcing an update won't necessarily stop the system from using the old version of your Help folder in an older version of your application.
When I am working on my Help folders, I routinely compress all older versions of the application into zip files for the duration, and I trash the Help caches before every test.
The typical user trashes the old version of the application when they install the new version, and all is well.
--
Bill Cheeseman -
I just get mad about the helpd cache while developing a help book as anything I found on the web, including what is found here, about clearing the cache of 'helpd' turn to not work anymore (at list on MacOS 12 - Monterey).
I found what do clear looking at files opened by HelpViewer Networking process while my help (not updated) was opened using Apple 'Activity Monitor.app'.
It turns that the cache is now built in the Container directory within your Library Folder.
~/Library/Containers/com.apple.helpviewer/Data
In this directory you find your cache help files in the form of
.*
e.g.
com.johnsmith.johnapps.com.johnsmith.johnapps.help*1.0.help/
doing a rm -rf of this directory will clear the help cache used by HelpViewer for the help book you are developing
You still need to kill the helpd daemon for this to work.
e.g.
rm -rf com.johnsmith.johnapps.com.johnsmith.johnapps.help*1.0.help/
pkill helpd
Note that changing the version of your help book in the plist file does not help.
In my case even if I increase the version of the plist help book (see Authoring Apple Help) , the cache generated still have version 1.0 even if it has been regenerated after the version update.
I worked on a chrome extension and uploaded it to chrome webstore and everything went well, I installed it on my Mac and on my Ubuntu machines in chrome it worked fine and installed. But when I try it on Windows machines, after download it popups a error message saying "Invalid Package, Can't unzip the extension".
Can any one tell me why or what might be the cause for this OS specific issue. Does it have anything to do with the permission or anything with respective folder name or content? The folder name or the extension name don't have any special characters and the previous version was fine.
Thanks in advance.
This is because there a file inside the package with a Windows invalid character in name or there a corrupted file. In my case I've tried to download the CouponsHelper extension and this error was displayed too.
I downloaded the CRX file manually and opened it with 7Zip. In the folder had a file named Icon. When I try to extract using 7Zip an error occurs too.
Note on the screenshot that there an invalid char in Icon file and that it is zero sized (possibly corrupted).
Another cause of this problem (Error: could not unzip extension) might be that you include the root directory in your zip.
You should zip all files in the same level of manifest.json.
Example
-yourappfolder
|_manifest.js
|_popup.html
In this case you should zip only manifest.js and popup.html, instead of zip the entire directory yourappfolder.
In other words, in your zip file you should NOT see the yourappfolder directory.
So the trick it to compress all the files within the folder not the folder itself.
NOTE: If it's saved in Google Drive (local syncing) this well mess it up too. Drive attaches little icons to folders that show up as unknown.
So remake the folder outside of Google Drive.
That's what was messing mine up after the "only compress inside of folder" fix.
I had the same problem but the reason was different.
I found that there is an image which has a name that is too long. When I replaced the name with a shorter one and built new package, it installed successfully.
I hope this helps anyone may facing the same problem.
A quick Google only turned up one possibly useful result but I wasn't sure if it would help.
Is that error message exactly what you see (i.e. word for word)? I couldn't find it in the code.
I may be wrong but I think this could be the code responsible for the error. Unfortunately, the zip::Unzip call can potentially fail for a number of reasons and only provides more details in the logs. I'm guessing such logs output to this location (Windows XP);
%USERPROFILE%\Local Settings\Application Data\Google\Chrome\Application\debug.log
None of this information may be useful to you but I thought I'd show you my investigation :)
Have you tried to install the extension again and do you have administration rights (not sure if this would have an affect here)?
I had the same problem but it was rejecting it because either the file was too big or the paths were too long (Windows...), which was because I accidentally included my entire node_modules directory in the .crx file.
It could be caused by a lot of things.
For me, the problem was having .xcf (Gimp) files inside the package.
The extension loaded fine when unzipped manually but showed the "couldn't unzip" error in when loaded from the Chrome Webstore.
I had problems with zipping with MacOS. There was a bunch of hidden files in the zip.
Using Windows solved it but probably taking not the default zipper in MacOS should do the same.
I had a similar problem.
My solution was:
unzip the CRX to a directory...lets say called freddy123
Rename "_manifest" to "manifest"..i.e remove the underscore.
Chrome->settings->More Tools->Extensions (Check Develop Mode Check box)
Load Unpacked extension (select freddy123 directory)
This worked for me.