I have a problem with my eZ Publish project after moving form a virtual machine to my localhost.
I get this in my error log:
/Publish/Core/FieldType/XmlText/Converter/Html5.php line 140
I think it's environment related as I had no such thing on my VM.
Found the problems...Seems that there was a blank(space) in the path to my project and when importing the xls file it didn't know to escape it so was ending execution without an error message even remotely connected to the problem. SO just make sure the path to your project doesn't contain any spaces; you will probably need to configure your virtual hosts also if using any. Hope it helps
Related
I am not very familiar with CapRover, but my company uses it to deploy local branches to staging server. I completed a task in a ruby and rails project and tried to deploy my branch using the caprover deploy command.
The build passes, but the deployed app webpage goes to error 502. In the App Logs, it prints repeatedly that it could not find docker-entrypoint.sh: /bin/sh: 1: docker-entrypoint.sh: not found
Now, I use Windows and my colleagues use Linux. They tried to replicate the deploy on their machines and it is passing normally. That's why the suspicions falls on Windows causing it with some characters incompatibility, like slashes or quotations marks... I don't know how can I try to correct this issue without modifying the project files that they are already using and risk causing some problems where it is working...
I am not sure if I provided enough information for someone to try to help me fix this issue? I will gladly try to provide more infos if required
Thanks
I'm attempting to sync my local PHPStorm project from my Windows 7 PC with my Ubuntu server.
When I try any kind of connection (e.g. "Test SFTP connection"), it fails with
Invalid descendent file name "C:\nppdf32Log\debuglog.txt"
the folder mentioned doesn't exist on my Windows machine, and of course not on my Ubuntu server.
Even the most basic operation connecting to the Ubuntu server is failing because of this - Jetbrains support suggested asking here, so does anyone have a clue?
You have a file on your Ubuntu server with that C:\nppdf32Log\debuglog.txt name. YES -- it's on Ubuntu and YES -- it's actually a file name and not full path (Linux allows : and \ characters in file names).
Unfortunately such file name is invalid on Windows and library used for SFTP communications in PhpStorm does not allow to process such files in any way (yes, it's valid as full path but not as file name alone).
The solution is to connect to your SFTP using another program (e.g. FileZilla) and delete that file. After that you will be able to continue with PhpStorm built-in SFTP functionality.
P.S.
Such file is usually created by Firefox on Linux (google that file name for additional details).
https://askubuntu.com/questions/144408/what-is-the-file-c-nppdf32log-debuglog-txt
Jetbrains support suggested asking here
That's odd (and hard to believe for me) -- they should know about such issue for sure -- you are not first who is facing the same error.
In any case -- this is the ticket to watch after -- hopefully the used library (for SFTP communications) will allow handling such situations better in the future.
http://youtrack.jetbrains.com/issue/WI-2449
I met with the same problem,
but I included logging of errors (description here https://devnet.jetbrains.com/docs/DOC-1202)
and I saw that I had created a file with incorrect name
I had this same problem, but it was not due to Firefox and I wonder if the original asker might have made the same mistake I did in configuring his xdebug.
As a newbie, in setting the value for xdebug.remote_log in my php.ini (actually in separate xdebug.ini), I used the windows file path to my project on my local machine. Why? Because the value called "remote_log", so I mistakenly thought it wanted the path on my windows machine, which I thought was very strange at the time. But I am new to remote debugging, so... Oops.
Using windows path is wrong:
xdebug.remote_log="C:\Users\Buttle\PhpstormProjects\xdebug_log.txt"
And it results in:
/var/www/myproject/C:\Users\Buttle\PhpstormProjects\xdebug_log.txt
(the bolded part is the actual file name)
This is right:
xdebug.remote_log="xdebug_log.txt"
And presumably results in:
/var/www/myproject/xdebug_log.txt
(the bolded part is the actual file name)
It appears that Xdebug saves that log file inside of the folder where the requested php file came from (in my case, my project's index.php file).
I imagine that if I enter an valid linux path, I might be able to put the file somewhere else. E.g.
This might work:
xdebug.remote_log="/var/www/xdebug_log.txt"
So this solves 2 problems: 1.) why the heck doesn't xdebug log anything on its server (it does!) 2.) descendant file problem.
I got Team Explorer Everywhere so we can use TFS on the Mac Mini we got to test Iphone apps. Since we're using XCode for phonegap, we need to use the commandline program and it is giving me a lot of grief.
What I've done so far (Listing out for anyone who stumbles on this so they can use it):
-Downloaded the trial (free)
-Set the path using PATH=$PATH\:/FOLDERLOCATION
-Accepted EULA and got trial product key... for command line program (tf eula/tf productkey -trial)
-Set up workspace:
tf workspace -new WORKSPACENAME -server:http://SERVERNAME:PORT/FILEPATH -comment:"WORKSPACENAME" && prompted for username -> domain -> password
-Trying to setup the folder path (Fixed):
tf workfold -map SERVERFOLDERPATH LOCALFOLDERPATH -collection:http://SERVERNAME:PORT/FILEPATH -workspace:WORKSPACENAME && prompted for username -> domain -> password
-Make sure I can check out/check in (On hold):...
The error I'm getting right now is "An argument error occurred: First free argument must be a server path." This is what I've been following ever since I got the path set, but I think the versions are different because mine doesn't seem to be set up the same. Any help at all would be appreciated, and I'll keep up with the post as I figure parts out because there doesn't seem to be much online that I can find on TFS on macs.
Update: As normal, I'm an idiot. Have to put the options at the end of the command and have to have the serverfolder path as the first thing after -map. Now I just need to figure out how to use the damn thing. I'll post any other questions I have and try to get all the correct commands up for the selfish reason of having them somewhere in case I forget them later.
Update 2: The mapping hasn't worked out as well as I'd hoped, it seems a combination of my unfamiliarity with Unix/Mac file systems and some settings being missing is keeping me from using 'tf get' to load all of the test data I was trying to get. I'm planning on trying again after I get the location of where my boss wants the data saved and after I can look into something that would save the workspace so it won't say that it can't find the map path every time...
It looks like you're setting up your workspace and some working folder mappings just fine, after the edit. If you're having problems doing a tf get after this, then there are some common problems that might be occurring. TFS workspaces can be a little bit opaque and having a better understanding of them can sometimes help you understand where the problem is:
Team Foundation Server requires a workspace to be configured before you can get files out of source control, edit them or check them back in. A workspace basically simply contains working folder mappings that map your local path(s) to server path(s).
Workspaces are stored on the server and are uniquely identified by your computer's hostname, your username and the workspace's name. A cache of this information for the local host is saved on the client. This implies:
If you remove a workspace on the server, your workstation will be unable to connect.
If you remove the cache, your local computer will not be able to identify the workspace based on working folder mappings until the cache is rebuilt (which happens every time you connect to the server.)
If you change your username or local workstation's name, you cannot access those workspaces.
(Note that very early versions of the Teamprise command line client had certain issues on Mac OS that made identifying the local workstation name difficult. This is fixed, however, in Team Explorer Everywhere.)
Because you can have multiple workspaces for a single server on a single workstation, you can't always simply provide server paths to tf commands, since server paths are ambiguous. ($/ exists in every workspace, for example.) So the command line client resolves paths based on the current working directory and/or the arguments provided. Meaning that you can run tf get foo.txt if you're in a working folder, or you can run tf get /tmp/foo.txt if /tmp is mapped.
One more point - the configuration data for Team Explorer Everywhere is shared between the TFS plug-in for Eclipse and the command line client. So if you're more comfortable using a GUI to set up your workspace(s), you can do that and then use the CLC as you see fit. You don't need to be a Java programmer to use Eclipse - simply download Eclipse and install the TFS plug-in for Eclipse into it, and select Window > Open Perspective > Team Foundation Server Exploring. After that, you'll have the full GUI Team Explorer experience and this perspective will be restored when you open Eclipse, so you won't even need to worry about the Java IDE bits if you don't want to.
I have been trying to publish my service to windows azure. The service consists of a single webRole, however I have added remote login functionality published it and built it a few times, and now all the sudden it will not build. The reason it gives is that
Details below:
"Error 56 The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files (x86)\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets 202 5 FileSystemCreator"
I have gone on all the forums, I have used CSPack command line for packaging the service which is fine but I'm having a really hard time configuring the certificate for remote desktop connect and I would like to take advantage of this feature as I am creating some websites in the onStart event and I would like to peek into IIS. Some microsoft employees do agree that this is a bug and the have promised a fix this issue, refer to post . I am using VS2010 and I do not know how to fix this bug.
Can anyone please help, or point me to a place where I can get any help.
I ran into the same problem with a new solution.
Note that, unlike Eugenio Pace's response suggests, the error occurs only when deploying to Azure (and not when running the project in the Azure Compute Emulator).
Try adding the following line to the first property group of your Windows Azure Visual Studio Project file (*.ccproj):
<ServiceOutputDirectory>C:\Azure\</ServiceOutputDirectory>
The trailing slash (for whatever path you select) appears to be required. This folder will be deleted each time you create a package if it exists.
This setting seems to redirect the working folder for the package to a shorter base path, preventing the path too long error.
Credit goes to: http://govada.blogspot.com/2011/12/windows-azure-package-build-error.html
Perhaps the local folder used to store temporary development fabric is too long. See Windows Azure - Resolving "The Path is too long after being fully qualified" Error Message.
I was having this problem as well when deploying a Node.js project to Azure.
To fix it, I had to change my "TEMP" and "TMP" user environment variables to something shorter than their default values.
In my case, they were pointing by default to %USERPROFILE%\AppData\Local\Temp, changing them to C:\Temp solved it.
Make sure you restart Windows after.
The better solution may be to create a symbolic link to your project folder. This doesn't require moving files or changing system variables. Open up the command prompt as an administrator and run this:
mklink /D C:\Dev C:\Users\danzo\Source\Workspaces
Obviously you can change "C:\Dev" to whatever you want it to be and you'll need to change the longer path above to the root directory of your soltions/projects folder.
Same problem happened to me when I try Packaging an Umbraco project for Azure (https://github.com/WindowsAzure-Accelerators/wa-accelerator-umbraco/wiki/Deployment), I found the solution is to: Copy and rename the long-name path and folder to "C:\someshortname".
(solution was suggested by this: link)
I tried all the above 2 approaches:
-change TEMP and TMP enviromental variables
-<ServiceOutputDirectory> path
and didn't work.
In my case, I had to move the whole project to a shorter path C:\ and worked.
I'm using W7 and VS12.
When you run a cloud service on the development fabric, the development fabric uses a temporary folder to store a number of files including local storage locations, cached binaries, configuration, diagnostics information and cached compiled web site content.
By default this location is: C:\Users\\AppData\Local\dftmp
Credit goes to Jim Nakashima of Microsoft :
https://blogs.msdn.microsoft.com/jnak/2010/01/14/windows-azure-resolving-the-path-is-too-long-after-being-fully-qualified-error-message/
In order to change the temporary folder, a user environment variable has to be created :
It is named _CSRUN_STATE_DIRECTORY
Give it a value of short named directory like :
c:\AzureTemp
Don't forget to restart Visual Studio in order to have the environmennt variables to be read again
It fixed many compilations problem !
I'm in the process of setting up a proper CI environment and am currently evaluation TeamCity. (So my TeamCity experience is non-existent.).
I've performed a default install of TeamCity 5.0.1 Professional in a clean Windows XP (for now) VM.
I've created my project and pointed it to my source repository and queued up a build.
However, I don't see any Build Agents installed/available via the Team City web interface. I've checked and there is a 'Team City Build Agent' service installed and it's running. I've also reviewed the log files in the buildAgent folder and don't see anything that would lead me to an error.
Is there a step or concept that I'm missing here on getting the default Build Agent to become available to Team City? I'm not trying to do anything complicated with the build. (at this point, I just want to pull my source down from the repository)
I had exactly the same problem. After going through settings, reinstalling the agent etc, I found that the problem was rather simple - the TeamCity agent placed a wrong teamcity URL in it's property (and other paths as well).
Find the buildagent.properties file ( buildAgentInstallDir\conf\buildagent.properties), and you'll probably see that all of the lines have 'escape' characters in them (e.g. serverUrl=http://localhost:8090/ )
Modify the file to remove escape chars (i.e. links should be plain like: serverUrl=http://localhost:8090/ , env.TEAMCITY_JRE=C:\Program Files\TeamCity\BuildAgentInstalled\jre and similar)
Hope this helps...
If your server is running on a machine with multiple IP addresses, the agent may fail to identify the correct IP address. You can explicitly set the IP address in the buildAgent/conf/buildAgent.properties file. You should see a section that is optional to set the IP of the buildAgent and the IP of the Teamcity server. I recommend trying both.
Right after a clean install you should see one build agent - the local machine. I don't think this has anything to do with you even having to have a project defined. IMHO you something went wrong with the installation.
Filip
If you've changed the TeamCity server port in conf/server.xml like:
<Connector port="8222" protocol=".."/>
You should change the default agent configuration in buildAgent/conf/buildAgent.properties
serverUrl=http://SERVER-IP-HERE:8222/