Jump to content

Beluga

Members
  • Posts

    523
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Beluga

  1. Whew! I got help from Caddy developer abiosoft and now I have a working ProcessWire config! It is included below. Note certain things: - the "php" in the fastcgi line defines a preset, so we don't need to use any "ext" stuff. - the new style rewrite which does not use {uri}: to {path} {path}/ /index.php?it={path}&{query} Abiosoft is also looking into a webtrees instance I have. So far the routing is solved by a workaround of adding a /slash to a certain line the webtrees index.php. Once the issue is solved properly, I can publish the Caddy config on the webtrees forum I urge everyone using Caddy with PW to donate bitcoins to abiosoft! https://mysite.com, https://www.mysite.com { root /wherever/your/files/are fastcgi / unix:/var/run/php-fpm/php-fpm.sock php internal /forbidden rewrite { r /\. to /forbidden } rewrite { r /(COPYRIGHT|LICENSE|README|htaccess)\.txt to /forbidden } rewrite { r ^/site(-[^/]+)?/assets/(.*\.php|backups|cache|config|install|logs|sessions) to /forbidden } rewrite { r ^/site(-[^/]+)?/install to /forbidden } rewrite { r ^/(site(-[^/]+)?|wire)/(config(-dev)?|index\.config)\.php to /forbidden } rewrite { r ^/((site(-[^/]+)?|wire)/modules|wire/core)/.*\.(inc|module|php|tpl) to /forbidden } rewrite { r ^/(site(-[^/]+)?|wire)/templates(-admin)?/.*\.(inc|html?|php|tpl) to /forbidden } # GLOBAL rewrite { to {path} {path}/ /index.php?it={path}&{query} } log /var/log/www/access.log { rotate { size 50 age 7 keep 5 } } errors { log /var/log/www/error.log { size 50 age 7 keep 5 } } }
  2. The polyfill dude is lacking free time to complete his work. Do help with the issues, if you want to see it progress.
  3. Well, I made a fresh install of PW3 under Nginx and it worked ok, so it seems something must have gone wrong with the transferring of the old site I did it with wget from OVH hosting ftp directly to the server. I will try again tomorrow, first downloading to my local machine. PW3 did not work OK with Caddy, though (some glitches in the admin).. but under time constraints I have to focus on Nginx now and abandon Caddy. Edit: confirmed that something went wrong the first time I transferred the site! I used wget and seems we cannot trust it to be reliable Now the old site works with Nginx. I am getting assistance from a forum user to get Caddy working.
  4. I included the class (from wire/modules/Process/ProcessPageType/ProcessPageType.module) and now the complaint switched to: Fatal error: Class 'InputfieldSubmit' not found in /var/www/sitename/pw/wire/modules/Inputfield/InputfieldButton.module on line 10
  5. Solved the blankness by adding this: fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; Status reads: pool: www process manager: dynamic start time: 19/Mar/2016:23:41:47 +0200 start since: 41625 accepted conn: 5 listen queue: 0 max listen queue: 0 listen queue len: 0 idle processes: 1 active processes: 1 total processes: 2 max active processes: 1 max children reached: 0 slow requests: 0
  6. Well it didn't deny me before (was not on localhost, had allowed my ip) and now I tried with the 3 lines commented out and same blankness. I never touched the params, but here they are: fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param REQUEST_URI $request_uri; fastcgi_param DOCUMENT_URI $document_uri; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param HTTPS $https if_not_empty; fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_NAME $server_name; # PHP only, required if PHP was built with --enable-force-cgi-redirect fastcgi_param REDIRECT_STATUS 200;
  7. It is not a fresh installation, it is a confirmed working installation. I tried the /status page before, but was unable to get it working. Now I searched for a more detailed example and found one. I made several modification passes to get it "working" and now it displays a blank page for me. Here is the modified block I added inside my server block: location ~ ^/(status|ping)$ { #access_log off; allow 127.0.0.1; allow (my ip address); deny all; include /etc/nginx/fastcgi_params; fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; } I enabled php-fpm access.log. The default log configuration gives me this entry when I access /status and see the blank page: - - 19/Mar/2016:23:42:27 +0200 "- " 200 Is there some recommended configuration with maximum info? When I access /ping, it does not print "pong" like described in the comments of the status page tutorial. So debugging php-fpm might not be hard, but now we are at a point where setting up the debugging method itself is proving hard
  8. I first tried to run a (confirmed working on a traditional Apache setup) PW instance on Caddy + PHP-FPM. Failing that, I tried running it with Nginx + the same PHP-FPM. I got the same error. I describe the error in the Caddy topic. As I get the exact same error both with Caddy and Nginx, everything else must be fine besides something with PHP-FPM. It is not a general PHP-FPM problem, as a simple phpinfo file in the web root runs fine. Here is my www.conf. Here is my php-fpm.conf (never touched it). Here is my php.ini. Here is my php-fpm service file. For the Nginx experiment, I used the server config from the Howtoforge PW on Nginx tut. OS is Arch Linux. I even asked help from the Caddy developers, including the one who provided the PW example config, but they were stumped. Is debugging PHP-FPM really this hard: practically impossible? If you think of something, please comment.
  9. Ok, guys, I'll go back to good old Apache + regular PHP tomorrow, so last chance to give any debugging tips..
  10. Ok, I have not tried customizing an admin theme. This topic was about the site side of things
  11. PW does not use SASS. You can build your sites with anything.
  12. Ah you mean having security by obscurity? http is an existing user and group at least in the Arch Linux automated install in OVH Kimsufi. Note that when I temporarily set security.limit_extensions to FALSE in php-fpm's www.conf, it makes the "Access denied" go away and change to "No input file specified". This was in the log after the change and access attempt: 10/Mar/2016:20:42:56 +0200 [ERROR 404 /] PHP message: PHP Warning: Unknown: failed to open stream: Success in Unknown on line 0 Unable to open primary script: /var/www/user/pw (Success)
  13. Folder and files owned by user and group: http Files were ftp'd directly from a working PW installation so permissions stayed intact. in /etc/php/php-fpm.d/www.conf I have: user = http group = http From sudo ps aux | grep php: root 4554 0.0 0.1 99696 7268 ? Ss 22:26 0:00 php-fpm: master process (/etc/php/php-fpm.conf) http 4555 0.0 0.0 99696 3500 ? S 22:26 0:00 php-fpm: pool www http 4556 0.0 0.0 99696 3500 ? S 22:26 0:00 php-fpm: pool www
  14. If I change the #GLOBAL rewrite to to {path} {path}/ /index.php?it={path}&{query} I get "Access denied" from my site root. If I visit index.php, I get the same fatal error as in my previous message. This rewrite setting seems to be the one that also produces the "Access to the script has been denied" error seen in the log. edit: the docs/blogs other sources are a bit confusing. I guess it should be {uri} instead of {path} after all, but the rewrite docs only speak of {path} and {uri} is mentioned in the blog and the source code. Yet, the net result was the same access denied.
  15. What you say seems to be in conflict with LostKobrakai's:
  16. isellsoap: maybe you could at least comment on the issues? As noted above, GitHub issues is such a weak bug tracker that the QA team cannot be formed. An external solution is needed to track bugs properly.
  17. Ok, now getting to the fun stuff. PHP message: PHP Fatal error: Class 'ProcessPageType' not found in /var/www/user/pw/wire/modules/LanguageSupport/ProcessLanguage.module on line 18 08/Mar/2016:21:06:48 +0200 [ERROR 200 /index.php] PHP message: PHP Fatal error: Uncaught Error: Call to a member function ready() on null in /var/www/user/pw/wire/core/ProcessWire.php:351 Stack trace: #0 /var/www/user/pw/wire/core/Wire.php(398): ProcessWire->___ready() #1 /var/www/user/pw/wire/core/Wire.php(333): Wire->runHooks('ready', Array) #2 /var/www/user/pw/wire/core/ProcessWire.php(404): Wire->__call('ready', Array) #3 /var/www/user/pw/wire/core/ProcessWire.php(324): ProcessWire->__call('ready', Array) #4 /var/www/user/pw/wire/modules/Process/ProcessPageView.module(227): ProcessWire->setStatus(4) #5 /var/www/user/pw/wire/core/Wire.php(398): ProcessPageView->___ready() #6 /var/www/user/pw/wire/core/Wire.php(333): Wire->runHooks('ready', Array) #7 /var/www/user/pw/wire/modules/Process/ProcessPageView.module(152): Wire->__call('ready', Array) #8 /var/www/user/pw/wire/core/Wire.php(398): ProcessPageView->___execute(true) #9 /var/www/user/pw/wire/core/Wire.php(333): Wire->runHooks('execute', Array) #10 /var/... PHP message: PHP Fatal error: Class 'ProcessPageType' not found in /var/www/user/pw/wire/modules/LanguageSupport/ProcessLanguage.module on line 18 I'm using pwFoo's config and the only thing I changed was this section: http://mysite.eu:80 { root /var/www/user/pw fastcgi / /var/run/php-fpm/php-fpm.sock { ext .php } PHP in itself works, as phpinfo(); works ok. Any tips on troubleshooting? Btw. I also noticed this in the error log: 08/Mar/2016:20:50:45 +0200 [ERROR 403 /] Access to the script '/var/www/user/pw' has been denied (see security.limit_extensions) So it seems "the script" is the folder name..? Is there any harm in that? I did try temporarily setting security.limit_extensions to FALSE in php-fpm's www.conf, but it was not the cause of the PHP fatal error.
  18. Does it really backup the files to a zip file as well and not only the db?
  19. I tried to install this on a 2.7 site and got this: It seems no other backup solution offers the feature to zip up the files. Well, I guess I could use the solution from Stackoverflow.
  20. https://caddyserver.com/docs/faq (don't want to spam, so edit): Wow, I just got this to work on an Arch Linux server Just testing with a static file for now. The package is in AUR: https://aur.archlinux.org/packages/caddy I used git clone and then the makepkg command. I did edit the .service file and remove -host="::" -port="80" as they did not seem to be working. It launched with HTTPS even with that -port parameter, so I put everything to the caddy.conf file. I noticed in the logs when it tried to create the Let's Encrypt cert that the user (http) could not write to /srv/http, so I did this to prevent confusion in the future: sudo chown http /srv/http I put the log files to a new folder and gave http user ownership: sudo mkdir /var/log/www sudo chown http /var/log/www
  21. Any more interesting problems discovered? pwFoo: did you get the frontend stuff working? If you are confident that it works flawlessly, the a guide could be added to https://github.com/caddyserver/examples
  22. Unfortunately, the shared hosting does not support SSH access Another minus..
  23. Ok, it seems the images were not the only problem after all. Still crashing and with this: Error: Exception: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away (in /home/sitename/www/wire/core/Pages.php line 2103) #0 /home/sitename/www/wire/core/Pages.php(2103): PDOStatement->execute() #1 /home/sitename/www/wire/core/Pages.php(546): Pages->executeQuery(Object(PDOStatement)) #2 /home/sitename/www/wire/core/PagesType.php(260): Pages->getById(Array, Object(Template)) #3 /home/sitename/www/wire/core/Users.php(33): PagesType->get(1122) #4 /home/sitename/www/wire/core/Session.php(102): Users->get(1122) #5 /home/sitename/www/wire/core/ProcessWire.php(279): Session->__construct() #6 /home/sitename/www/wire/core/ProcessWire.php(94): ProcessWire->load(Object(Config)) #7 /home/sitename/www/index.php(232): ProcessWire->__construct(Object(Config)) #8 {main} and also the max_user_connections error. I think the user was in the admin trying to expand some pages for editing, at least he said so to me. Yet the big choking seems to be gone. I personally did not encounter any problems with quick testing.
  24. So what is the mechanism that wrong permissions cause files to not be skipped? The files that seemed to be in a processing loop were huge pngs (two files, 14.3M and 9.5M). It had done processing on them at 05:40 in the morning. I replaced them with jpgs. Now the problem seems to be gone. However, images these days are big. I need the memory headroom so I will continue to try to get the Kimsufi server.
  25. Now I checked with FTP and to my dismay, there are freshly generated -pim2 versions in the assets! What should I be looking for regarding permissions? Images are 0644 and asset folders 0755. Thanks for the insight. As you can guess, this has been a major pain in the butt for weeks. That said, when I started using PIM and generated the files for a gallery, it already choked on the first run. So I think I have to get the Kimsufi in any case. It will also enable users to upload files larger than 60M without me having to do a workaround with PW API every time.
×
×
  • Create New...