Bit of an obscure one this. My setup is all running on my local Windows machine; I've got NetBeans IDE installed, a local XAMPP server with XDebug running, and an installation of Moodle with some custom addons in the mod directory.
I can happily create breakpoints in PHP pages (including the main Moodle ones), but any breakpoints I place on php files in the mod directory never fire (on my mods, or any of the inbuilt ones). I thought Moodle might be doing some "magic" to display files in the mod directory, but my browser shows the url as http://localhost/moodle/mod/view.php - and that's the file I've set my breakpoint in.
Has anyone got any experience with debugging Moodle addins, or could possible point me in the direction of how to troubleshoot the breakpoint not firing? I've tried the Moodle site, but can't find anything relevent.
Actually, I think I've figured it out. If I tell it to debug that particular file it will 404 (it doesn't put the directories in, guess it's a bug), but if I then manually go to http://localhost/moodle/mod/view.php?XDEBUG_SESSION_START=netbeans-xdebug (which errors, no parameters are being passed in), and THEN manually navigate to Moodle then my mod breakpoints fire correctly.
All very bizarre, but it seems to be a usable workaround. I'm guessing the mods are running under some kind of different PHP session.
I'll keep this answer here in case anyone else has this bizarre problem.
Related
I've been developing a website built on OctoberCMS, using the Laravel Homestead vagrant box as my local development server and have so far been getting along swimmingly. I developed most of a theme this way.
However I've recently started running into a problem wherein requests for assets/vendor.css in the theme assets succeed but receive a text/html response containing HTML for the homepage instead of the proper CSS.
This means vendor CSS for the page doesn't load. However if you repeat the request for vendor.css with "open in new tab" after page load the correct asset is returned, and the Chrome 'sources' tab also shows the correct asset.
This strange behaviour seems to extend to JS assets. I'm currently looking at a request for assets/vendor/jquery.js where the inital response actually contains the contents of assets/theme.css - and this is causing JS errors in the console.
In this case however if I make the request to that URL again I actually still receive the same incorrect CSS, but once again the Chrome 'sources' tab actually shows the correct asset.
Inspecting the files in my code editor I see the correct assets under the correct filenames and locations.
It seems I might have an issue with Homestead's web server. However I'm confused about where it might have come from as I haven't reconfigured anything and this has been working fine previously.
I've confirmed that the problem still persists even after deleting the homestead VM, and then building a brand new one and installing a fresh copy of OctoberCMS, without importing any of my own custom theme files.
I tried having a look into the nginx logs on the VM to see if I could spot anything odd, but it looks like they all have no content, 0 lines.
I'm a bit stumped and haven't found much helpful searching around.
Any suggestions? Help much appreciated.
So I've managed to re-build my project in such a way that this time I didn't reproduce the problem.
I'm pretty sure that ultimately it was caused by the fact that I relocated the homestead VM (and projects therein) by renaming its containing folder.
In previous attempts I had been deleting the VM by running vagrant destroy and then re-creating it by running vagrant up.
Once I completely deleted the homestead repository and re-cloned it from scratch from laravel/homstead on github, then proceeeded to vagrant up and set up OctoberCMS, I no longer experienced the issue.
I suspect perhaps the original path to my VM (before rename) was still in a configuration file somewhere in the laravel/homestead project and the disconnect between this value and the actual filepath was causing the problem.
I've been working on setting up correctly my xdebug debugger so I can improve my soft dev process, I manage to get xdebug working with phpstorm for some files that are outside of the project as in the first picture. But when it comes to debug some of the files that are inside of my mvc project (my app folder) I can set my debbuger to work properly and as far as now Im kind of stuck so any help would be welcome.
When I debbug phptest.php it work perfectly because it's an easy mapping
But when I need to debbug something like any php script on my controller folder for example, I can't get to there.
So please any ideas on how to do this.
Regards
Added a new screen shot of my mappings settings as #rafail pointed :)
For further or similar problems, my error was that i added index.php to my excluded paths and because of that I was never be able to debug, I deleted it and now it works fine.
especial thanks to Rafail Akhmetshin for his patience help.
Resume:
Check for exclude paths
Start debugging with phpStorm button
Make sure you are listening on the port
as a note point
make sure to check/uncheck
break at first line on php code
and break on first line when no mapping
Currently I am trying to run a Wordpress repo locally for development. I am not using MAMP pro even though I still have a 9 day trail. I figured since I'm going to be using the free version for now I might as well work with that. I have my Apache & MySQL server running along with the Document Root pointing to my Sites folder where my projectName repo sits. I'm still running off of the default port of Apache 8888.
After I start the servers, I open WebStart and import my DB into phpMyAdmin. Everything works perfectly fine and the copy of my db gets imported. I then make sure that my wp-config.php file has the appropriate settings to access this db. I then click on My Website. This pulls up the content of the website. However, it does not pull in any of the assets(imgs/js/css). I receive the following errors in the console:
Failed to load resource: net::ERR_EMPTY_RESPONSE http://projectName.dev/wp-content/uploads/2016/09/logo-footer-1.png
Failed to load resource: net::ERR_EMPTY_RESPONSE http://projectName.dev/wp-content/themes/projectName/images/circle.png
And so the list goes on and on for pretty much every asset the project could possibly have. Now configuration is NOT my strong suit, and at this point I am at a loss of what could possibly be happening. Awhile ago I did follow a tutorial on how to setup my files so that I can access them in the web browser by simply typing the name of the project with the domain .dev, example: projectName.dev. I started having issues with this after upgrading to OS Sierra and it no longer works. Could this possibly be the reason as to why it is looking for these assets in the projectName at the .dev domain?
I apologize if this does not make sense. I am willing to provide anyone with any information on this as I need as much help as possible because I still need to level up my configuration skills. Let me know if you have questions.
The images and other assets are referenced with an absolute filepath (i.e. the URL of the server on which you first set it up). This has to be changed in all database entries. There are tutorials for this on the net, but the most simple version is to open the sql file in an editor and search & replace the general URL part in the complete database.
Be sure to keep a backup of the file - that might not work on the first try...
I am working on a moodle based project, which I inherited from someone else. Having copied the files into htdocs folder and started MAMP, the files still don't show in the browser. Instead, the browser automatically initiates a download. I might be required to change the config file, however, since I do not have much experience with php and SQL I am not sure what exactly. My part of the project is to develop html and css, but need to be able to run it locally first.
What do I need to do to get the files run locally? The route I use is localhost:8888/whatever/whatever/index.php
In case someone else runs into the same problem - Apache downloads php files instead of reading them - here is what helped me.
.htaccess file may need changes if the application has changed servers.
Delete (at least rename if you don't want to remove it) config.php and run the application through the browser. It should initiate install automatically.
To run php and SQL I used MAMP.
I have just moved a silverstripe install to a new joyent smartos server. Not being familiar with Linux, this was still relatively easy.
I am new to silverstripe as well, but the team here has developed on it for years.
I have the site up and running on the new server, but have not pointed the domain to it until we can thoroughly test it. So I am accessing it from it's ip address. The site displays fine and the sub pages work as well. When I navigate to the '/admin' page, I see a silverstripe page that states the page cannot be found (not an Apache 404). I copied over the .htaccess and the _config.php from the old server, so there should be no issues.
I have done a /dev/build with no errors and I can log in through the security page, but I just cannot get the /admin to come up. I am lost after spending the whole morning surfing google to find the answer. Any help would be greatly appreciated.
UPDATE:: I installed a fresh version of silverstripe into a subdirectory on the same server. Works perfectly, so that rules out any PHP issues.
I have also tried /index.php/admin with no luck.
Thanks,
Ben
I was having this problem as well. None of the solutions I found online worked for me, but I managed to figure it out.
I had apache running as a non-standard user, and the problem turned out to be that the webserver was unable to save session data for the logins.
The solution in my case was to chown root.myuser /var/lib/php/session. Once done, the admin page loaded fine.
If /admin is not loading at all and there is no 404 error, there is a high chance of a PHP error. And that should be logged in the webserver's log file. This will depend on your operating system and probably on the Joyent environment (not familiar with that breed of cloud computing). On Debian, Ubuntu, and some more it's /var/log/apache2/error.log (assuming you're using Apache).
If I had to guess, I'd say the permissions of assets/_combinedfiles/ are bad. The webserver tries to create some combined JS and CSS files there (specifically leftandmain.js and cmsmain.js) and if it fails, you might get the dreaded white page of death in /admin.