Het updaten van macOS via de App Store gaat bij mij niet altijd even snel. Na een snelle zoektocht kwam ik er achter dat het updaten ook via de terminal kan met het softwareupdate commando:
Updating macOS through the App Store can take a very long time — for me it’s typically around 30 mins of rebooting and waiting. macOS has a built in softwareupdate utility, which is much faster.
https://9to5mac.com/2017/07/20/how-to-update-mac-using-terminal/
Als WordPress ontwikkelaar maak ik veel gebruik van de command line. Tijdens het ontwikkelen van WordPress oplossingen werk ik namelijk veel met command line tools zoals git, npm, grunt, gulp, composer, etc. Andere zaken regel ik weer liever via een app. Gelukkig kunnen deze vaak ook eenvoudig via de command line opgestart worden. Voor Sublime en SourceTree gebruik ik daarvoor de volgende commando's:
➜ wp-pronamic-ideal git:(develop) subl .
➜ wp-pronamic-ideal git:(develop) stree .
Deze commando's openen automatisch Sublime Text 3 of SourceTree met de huidige project map. Hoe je deze commando's beschikbaar kunt maken is te lezen in de volgende artikelen:
Na het installeren van PHP 7.1 via Brew kreeg ik via de WordPress HTTP API soms de volgende foutmelding te zien:
cURL error 56: SSLRead() return error -9806
Ik was deze fout wel vaker tegen gekomen, maar het is altijd weer even zoeken naar de oplossing. Het belangrijkste is dat er gewerkt wordt Homebrew curl en openssl:
brew uninstall git brew uninstall curl brew install openssl brew install libressl brew install curl --with-openssl brew install php71 --with-homebrew-curl --with-homebrew-libressl --build-from-source brew install php71-xdebug brew install php71-mcrypt
Verder zijn ook de volgende Homebrew packages handig om te installeren:
brew install svn brew install git --with-brewed-curl --with-brewed-openssl --with-brewed-svn --without-completions brew install git-ftp brew install git-flow brew install composer brew install php-code-sniffer brew install phpmd brew install phpunit brew install phpmyadmin
Bovenstaande commando’s lijken het probleem niet altijd op te lossen. Eventueel kan onderstaande dan geprobeerd worden:
brew reinstall curl --with-openssl
De Homebrew curl formule is ‘keg-only’, maar om er zeker van te zijn dat Homebrew curl formule gebruikt wordt linken we deze wel:
brew link curl --force
Ook zorgen we er voor dat de Homebrew curl formule gebruikt wordt in de shell:
echo 'export PATH="/usr/local/opt/curl/bin:$PATH"' >> ~/.zshrc
Als het goed is geeft het volgende commando nu het volgende resultaat:
curl --version
curl 7.55.1 (x86_64-apple-darwin16.7.0) libcurl/7.55.1 OpenSSL/1.0.2l zlib/1.2.8 libssh2/1.8.0 Release-Date: 2017-08-14 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy
Met name de OpenSSL/1.0.2l is hierbij belangrijk. Daarna gaan we PHP 7.1 opnieuw installeren met Homebrew curl:
brew reinstall php71 --with-homebrew-curl
Als het goed is geeft het volgende commando nu het volgende resultaat:
php -i | grep "SSL Version"
SSL Version => OpenSSL/1.0.2l
Na het updaten van MariaDB via Brew naar versie 10.1.8 had ik problemen met het opstarten van de MySQL server.
~ mysqld 2015-10-28 10:45:19 140735257919488 [Note] mysqld (mysqld 10.1.8-MariaDB) starting as process 1069 ... 2015-10-28 10:45:19 140735257919488 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Using mutexes to ref count buffer pool pages 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: The InnoDB memory heap is disabled 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Memory barrier is not used 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Compressed tables use zlib 1.2.5 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Using CPU crc32 instructions 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Initializing buffer pool, size = 128.0M 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Completed initialization of buffer pool 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Highest supported file format is Barracuda. 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: The log sequence numbers 2407038528 and 2407038528 in ibdata files do not match the log sequence number 2407038728 in the ib_logfiles! 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Database was not shutdown normally! 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Starting crash recovery. 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Reading tablespace information from the .ibd files... 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Restoring possible half-written data pages 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: from the doublewrite buffer... 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: 128 rollback segment(s) are active. 2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Waiting for purge to start 2015-10-28 10:45:19 7000008b1000 InnoDB: Assertion failure in thread 123145311424512 in file btr0cur.cc line 5341 InnoDB: Failing assertion: rb_ctx != RB_NONE InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 151028 10:45:19 [ERROR] mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. To report this bug, see http://kb.askmonty.org/en/reporting-bugs We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Server version: 10.1.8-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=0 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467104 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x0 thread_stack 0x48000 0 mysqld 0x000000010f93bd21 my_print_stacktrace + 61 0 mysqld 0x000000010f3dfffc handle_fatal_signal + 632 0 libsystem_platform.dylib 0x00007fff9501552a _sigtramp + 26 0 ??? 0x0000000000000009 0x0 + 9 0 libsystem_c.dylib 0x00007fff9f50237b abort + 129 0 mysqld 0x000000010f782e39 _ZL28btr_check_blob_fil_page_typemmPKhm + 0 0 mysqld 0x000000010f8cf80d _Z14row_purge_stepP9que_thr_t + 2334 0 mysqld 0x000000010f8a2a1a _Z15que_run_threadsP9que_thr_t + 822 0 mysqld 0x000000010f8f9862 _Z9trx_purgemmb + 2812 0 mysqld 0x000000010f8eccb1 srv_purge_coordinator_thread + 2484 0 libsystem_pthread.dylib 0x00007fff94b169b1 _pthread_body + 131 0 libsystem_pthread.dylib 0x00007fff94b1692e _pthread_body + 0 0 libsystem_pthread.dylib 0x00007fff94b14385 thread_start + 13 The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash.
Aangezien ik geen MariaDB/MySQL expert ben heb ik niet de oorzaak van dit probleem kunnen vinden. Gelukkig kun je met Brew eenvoudig terug naar een oudere versie.
brew switch mariadb 10.0.21
Hiermee was het probleem direct opgelost.
Na het update van Brew pakketten liep ik tegen de volgende foutmelding aan:
PHP Warning: PHP Startup: tidy: Unable to initialize module Module compiled with build ID=API20131226,NTS PHP compiled with build ID=API20131226,NTS,debug These options need to match in Unknown on line 0
Dergelijke problemen zijn vaak eenvoudig op te lossen door pakketten even opnieuw te installeren vanuit de bron:
brew reinstall php56-tidy --build-from-source
Ik heb op mijn blog al regelmatig geschreven over Homebrew (brew), PHP en Composer. Soms komt het voor dat bij het uitvoeren van een Composer commando memory limit fouten optreden. Bijvoorbeeld:
$ composer update Loading composer repositories with package information Updating dependencies (including require-dev) PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted at Zend/zend_vm_execute.h:551 (tried to allocate 32 bytes) in phar:///usr/local/Cellar/composer/1.0.0-alpha8/libexec/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52
Dergelijke fouten zijn vrij eenvoudig op te lossen door de memory limit te verhogen. Dit kan eenvoudig door in het PHP configuratie bestand de memory limit te verhogen.
Hiervoor moet je echter wel weten wat de locatie is van PHP configuratie bestand. Met Homebrew is dit gelukkig eenvoudig te achterhalen. Hiervoor moeten we eerst weten van welke PHP versie we gebruik maken:
$ php -v
PHP 5.6.3 (cli) (built: Nov 16 2014 12:01:32) (DEBUG)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies
with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans
Vervolgens kunnen we met het Homebrew info commando aanvullende informatie opvragen:
$ brew info php56
Dit commando zal de nodige informatie geven over PHP en onder het kopje “Caveats” zal de locatie van het PHP configuratie bestand vermeld staan:
The php.ini file can be found in:
/usr/local/etc/php/5.6/php.ini
Vervolgens kan dit bestand met behulp van nano eenvoudig aangepast worden.
nano /usr/local/etc/php/5.6/php.ini
De memory_limit kan vervolgens eenvoudig aangepast worden van bijvoorbeeld:
; Maximum amount of memory a script may consume (128MB) ; http://php.net/memory-limit memory_limit = 1024M
naar:
; Maximum amount of memory a script may consume (128MB) ; http://php.net/memory-limit memory_limit = 4096M
Met behulp van het volgende commando kan gecontroleerd worden of de wijziging goed is doorgevoerd:
$ php -i | grep memory_limit
memory_limit => 4096M => 4096M
Soms wil je even een statische kopie van een website maken voor offline gebruik of als backup. Met behulp van wget kan eenvoudig een kopie gemaakt worden:
wget --mirror --convert-links --adjust-extension --page-requisites --no-parent http://example.org
De wget tool neemt echter niet altijd alle gekoppelde stylesheets, scripts, afbeeldingen, etc. mee. Om een betere kopie te krijgen kan het daarom handig zijn om gebruik te maken van HTTrack. Met behulp van brew is deze tool eenvoudig te installeren op een Mac:
brew install httrack
Vervolgens kan met het httrack commando eenvoudig een kopie van een website gemaakt worden.
Bij het importeren van een grote WordPress database in mijn lokale MariaDB database server liep ik tegen de volgende fout aan:
ERROR 2006 (HY000) at line 40786: MySQL server has gone away
Na wat zoeken op internet kom je al snel berichten tegen dat dit te maken heeft met de ‘max_allowed_packet‘ configuratie instelling.
Na wat zoeken heb ik in mijn gebruikersmap (~) een MySQL configuratie bestand (~/.my.cnf) aangemaakt volgens de MariaDB documentatie.
Door hier het volgende in te zetten is de ‘max_allowed_packet’ instelling eenvoudig te verhogen.
[mysqld] max_allowed_packet=1073741824
Vervolgens kan MariaDB database server eenvoudig herstart worden met behulp van het volgende commando:
mysql.server restart
In dit bericht zal ik kort samenvatten hoe mijn MacBook Pro installatie er uit ziet qua programma’s, tools, addons, etc..