• Content Count

  • Joined

  • Last visited

Community Reputation

23 Excellent

About Lenz

  • Rank
    Jr. Member

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

616 profile views
  1. Lenz

    That'd be great! +1
  2. Lenz

    aha, now it's clear. @ryan Thanks a lot for clarifying this. Also thanks for the hint @fbg13
  3. Lenz

    Thank you very much for these new and - as always - useful features. I have a question regarding the update of pagination module (MarkupPagerNav) to automatically populate $config->pagerHeadTags. @ryan you explained: To use, simply populate them in your document <head> after pagination has been rendered [...] So, do you mean i have to insert some code within the <head> tags in order to generate <link rel='next'> and <link rel='prev'> tags? - If so: How exactly would i accomplish this task? I've heard the first time of $config->pagerHeadTags, neither found documentation in https://processwire.com/api/ref/config/ nor in https://processwire.com/api/ref/markup-pager-nav/ . But then again i think i wouldn't have to do anything manually if the modules populates $config->pagerHeadTags automatically? Surely i misunderstood something basic here. Thanks in advance for some enlightenment.
  4. Lenz

    Did also my small contribution. Thanks @adrian for rightly reminding us to show our appreciation for Processwire where possible. Processwire really should be recognized much more in the world. Maybe it'd be a good idea to place a github link directly on the starting page additionally to the one on the download page...?
  5. duh, 10 °C is really a damn frigid room temperature. I also had problems with my furnace connected with a rather serious and complex water pipe break. The heating installer needs 3 weeks to repair the damage, in part because he wasn't able to discover all the defects properly / immediately...
  6. Hello @abdus, congrats on your really great venture. Much appreciated. Is there any news about your newsletter module?
  7. Lenz

    @Bergy Sure, no problem. The scripts make some assumptions: 1. you have ssh access to your server 2. you not only have access to your document root (-> mostly /var/www ...etc), but also to your /home/user directory 3. your /home/user is at the same time your ssh user 4. your rsa public key is located under /home/user/.ssh/o2u_rsa 5. All scripts are located under /home/user/ For more comfort register a (RSA) key of your client computer to the development remote server (with keygen you can easily create a key on your machine under linux) you also can generate a key under windows with putty (with some plugins, google therefor putty generate ssh key, ssh authentification without password). # explanation regarding the use of placeholders in the scripts: # all placeholders are indicated with double braces -> {{ ... }}. Don't put your concrete names/data at all in braces, the double braces only indicate a placeholder # {{dev dbname}} is a placeholder for your database name on the development server/webspace. EDIT: Or is it actually the db-username? # {{prod dbname}} is a placeholder for your database name on the production server/webspace. EDIT: Or is it actually the db-username? # {{dev server user}} is a placeholder for your username on the dev server/webspace. # {{prod server user}} is a placeholder for your username on the prod server/webspace. # {{prod.server.name}} is a placeholder for your production server name. These scripts are working successfully at my hoster Uberspace The hosting os used by my hoster is Centos Linux (6) Feel free to correct me, or optimize things, always glad if i can learn something Now the Following describes the scenario Deployment of a new dev version of a website to the production environment / server / webspace The main script is deploy-dev-prod.sh. It executes 2 further scripts, like a php include. Code deploy-dev-prod.sh #!/bin/bash # Deployment Script: # Deploys the website from development environment to production environment # should be placed in your /home/user folder on the server # Usage: # # chmod +x deploy-dev-prod.sh # ./deploy-dev-prod.sh # If a sqldump-dev-backup.sql File already exists rename sqldump-dev-backup.sql to sqldump-dev-backup2.sql if [ -e sqldump-dev-backup.sql ] then mv sqldump-dev-backup.sql sqldump-dev-backup2.sql printf "\nSource Server: Done - rename sqldump-dev-backup.sql to sqldump-dev-backup2.sql\n\waiting for next step ...\n\n" fi # create MySQL dumpfile on source server mysqldump {{dev dbname}} > sqldump-dev-backup.sql # Attention: mysqldump --databases {{dev dbname}} > name.sql would export the database per se, which is not desired here. In our case only the tables should be exported in order to not need to adjust the database credentials on the target server (-> site/config.php). if [ "$?" -eq "0" ] then printf "\nSource Server: Done - create sqldump-dev-backup.sql\n\nwaiting for next step ...\n\n" # if creation of sqldump-dev-backup.sql was successful, remove sqldump-dev-backup2.sql, 1 backup is sufficient if [ -e sqldump-dev-backup2.sql ] then rm sqldump-dev-backup2.sql printf "\nSource Server: Done - remove sqldump-dev-backup2.sql\n\nwaiting for next step ...\n\n" fi else printf "\nSource Server: Error: creation of sqldump-dev-backup.sql failed\n\n" fi # rsync sqldump-dev-backup.sql to production server/webspace in ~ (= home folder) rsync -e 'ssh -i /home/{{dev server user}}/.ssh/o2u_rsa' -vaH /home/{{dev server user}}/sqldump-dev-backup.sql {{prod server user}}@{{prod.server.name}}:/home/{{prod server user}}/ # Was rsync successful? if [ "$?" = "0" ] then printf "\nDone - sending file sqldump-dev-backup.sql to target server\n\nwaiting for next step ...\n\n" else printf "\nError - sending file sqldump-dev-backup.sql to target server failed\n\n" fi # Backup Target Server (Auth via SSH Key) ssh -i ~/.ssh/o2u_rsa {{prod server user}}@{{prod.server.name}} 'bash -s' < backup-prod-server.sh # rsync cms processwire site/ files from dev to prod rsync -e 'ssh -i /home/{{dev server user}}/.ssh/o2u_rsa' -vaH --log-file=rsync.log --exclude=config.php --exclude=assets/cache {{/absolute/path/on/your/dev/webspace/to/processwire/site/}} {{prod server user}}@{{prod.server.name}}:{{/absolute/path/on/your/prod/webspace/to/processwire/site}} # attention: the dev path (= source) has a trailing slash, the prod path (= target) hasn't ! Because we want to copy THE CONTENT of /dev/site/ to prod/site # Was rsync successful? if [ "$?" = "0" ] then printf "\nDone - rsync content of site folder with target server\n\nwaiting for next step ...\n\n" else printf "\nError - rsync site folder failed\n\n" fi # Update CMS Database Target Server (Auth via SSH Key) ssh -i ~/.ssh/o2u_rsa {{prod server user}}@{{prod.server.name}} 'bash -s' < update-prod-server.sh backup-prod-server.sh #!/bin/bash # This script is part of deploy-dev-prod.sh and shouldn't be executed standalone. # if a sqldump-prod-backup.sql file already exists, rename sqldump-prod-backup.sql to sqldump-prod-backup2.sql if [ -e sqldump-prod-backup.sql ] then mv sqldump-prod-backup.sql sqldump-prod-backup2.sql printf "\nTarget Server: Done - rename sqldump-prod-backup.sql to sqldump-prod-backup2.sql\n\nwaiting for next step ...\n\n" fi # create MySQL dumpfile on target server mysqldump {{prod dbname}} > sqldump-prod-backup.sql # Attention: mysqldump --databases {{prod dbname}} > name.sql would export the database per se, which is not desired here. In our case only the tables should be exported in order to not need to adjust the database credentials on the target server (-> sit/config.php). if [ "$?" -eq "0" ] then printf "\nTarget Server: Done - create sqldump-prod-backup.sql\n\nwaiting for next step ...\n\n" # if creation of sqldump-prod-backup.sql was successful, remove sqldump-prod-backup2.sql, 1 backup is sufficient if [ -e sqldump-prod-backup2.sql ] then rm sqldump-prod-backup2.sql printf "\nTarget Server: Done - remove sqldump-prod-backup2.sql\n\nwaiting for next step ...\n\n" fi else printf "\nTarget Server: Error: creation of sqldump-prod-backup.sql failed\n\n" fi # copy {{/path/to/site/}} as backup to ~/site-backup/ if [ ! -d site-backup ] then mkdir site-backup fi # always delete an existing folder before copying content into a folder with the same name rm -R site-backup && cp -R /absolute/path/to/site/ site-backup # was site backup successful? if [ "$?" = "0" ] then printf "\nTarget Server: Done - backup current site folder\n\nwaiting for next step ...\n\n" else printf "\nTarget Server: Error - backup current site folder failed\n\n" fi and finally update-prod-server.sh #!/bin/bash # This script is part of deploy-dev-prod.sh and shouldn't be executed standalone. # # import database tables of source server into database of the target server mysql {{prod dbname}} < sqldump-dev-backup.sql # was import of sql dumpfile successful? if [ "$?" -eq "0" ] then printf "\nTarget Server: Done - import sqldump-dev-backup.sql\n\nDeployment finished successfully. Now reload the website" else printf "\nTarget Server: Error: import of sqldump-dev-backup.sql failed\n\n" fi For updating Processwire i use pw-upgrade.sh: #!/bin/sh # credits to https://gist.github.com/craigrodway/66c9633ae5d865a9b090 # # ProcessWire upgrade script # # Upgrades ProcessWire ./wire directory. # Use either master or dev branch. # # # Usage: # # chmod +x ./pw-upgrade.sh # ./pw-upgrade.sh # go 1 level over document root: cd {{/absolute/path/to/one/level/over/document-root}} # replace this path with your actual path without curly brackets # if processwire-master-backup exists, rename processwire-master-backup to processwire-master-backup2 if [ -e processwire-master-backup ] then mv processwire-master-backup processwire-master-backup2 printf "\nDone - rename processwire-master-backup to processwire-master-backup2\n\nwaiting for next step ...\n\n" fi # rename processwire-master to processwire-master-backup mv processwire-master processwire-master-backup printf "\nDone - rename current processwire-master to processwire-master-backup\n\nwaiting for next step ...\n\n" # download new version as tmp.zip - unzip it - and remove tmp.zip afterwards wget -qO- -O tmp.zip https://github.com/processwire/processwire/archive/master.zip && unzip tmp.zip && rm tmp.zip if [ "$?" -eq "0" ] then printf "\nDone - downloaded new master\n\nwaiting for next step ...\n\n" else printf "\nError - Download of new master failed\n\n" fi # delete processwire-master-backup2 rm -r processwire-master-backup2 if [ "$?" -eq "0" ] then printf "\nDone - removed processwire-master-backup2 because we need only one backup version\n\nwaiting for next step ...\n\n" else printf "\nError - processwire-master-backup2 couldn't be removed\n\n" fi # in html/ delete wire and index.php and replace it with wire and index.php from new processwire-master cd html/ rm -R wire && rm index.php && cp -R ../processwire-master/wire/ wire && cp ../processwire-master/index.php index.php if [ "$?" -eq "0" ] then printf "\nDone - replace wire and index.php with the ones from new processwire-master\n\n" printf "\nUpgrade finished - now login in CMS backend and do some reloads\n\n" fi Hope this is a bit of a help or inspiration. Feel free to give me your opinion. The only problem is, i'll be on holidays the next 10-12 days and not available. But afterwards i have a look at this thread.
  8. Lenz

    Interesting topic: I'm a bash scripter too. I usually have 2 remote webspaces: 1 htaccess-password protected dev environment and 2. a production environment. Both envs are exactly speced the same. At the beginning the production environment is the development-environment and is password-protected. Once the first release of the website is published, the htaccess protection will be deleted and a clone of the production website via bash script is going to be deployed to the development environment. Both environments authenticate passwordless against each other via RSA public key through SSH. The scripts do an incremental file backup and sync and a database backup and sync. dev can be deployed to prod and vice versa with a single command in bash. (or via putty under windows) Updating Processwire to a new version is also done with a bash script, first in dev, afterwards, if all runs smoothly, i run the deployment script dev -> prod. My IDE (Netbeans) is connected via SFTP to the dev environment. Bottom line is i need 3 scripts: deploy-dev-prod.sh deploy-prod-dev.sh update-pw.sh This workflow is a bit static though, if e.g the content of the production site is changing heavily DURING development of the development site (where structural changes take place, like changes in the pages hierarchy, new content structures or others) problems arise.
  9. wow congrats on this hell of an achievement, also demonstrating the power of processwire as an app development framework.
  10. Thanks again @Robin S. I think i'll go with the Profield. As i understand, it should also be frontend editable via a modal. This way i have the best editing experience and at the same time i support the Development of Processwire. Thanks @all for your help.
  11. Thanks for your explanation, @Robin S makes sense. Ok, one question: If i have 150 items, should i better go with the Profield table or is a Repeater enough? I really like the nice unbloated editing view of the table field. Does it scale better? Is it also like a Repeater accessible for frontend editing (via modal)? Video of current fancy editor: Problem is, the editor is not working anymore, so unfortunately i could not show you a video. The editor called unify, but it's not developed anymore and the business around it is gone. It was essentially a ajax frontend without a database for managing content for static sites (directly write into the files). At this point i fear i made a mistake in describing the editing experience: If i remember correctly you actually also have a modal layer, as soon as you edit content - but it loads the page layout - so you edit wysiwyg. Dragging / sorting rows was indeed possible directly inline without a modal though. Similar editors are https://sitecake.com/ and http://www.coast-cms.de/ but i'd like to use Processwire edit: Thanks @Robin S for refering to my question regarding table field and frontend editing. Could perhpaps someone confirm that also the table field is frontend editable?
  12. @Robin S haven't try this yet. But you're right, many requirements would be met with your suggestion. Obviously i'm a bit unclear, indeed: So my wish is to edit directly inline wysiwyg without a modal layer, like you do e.g. with textareas. But meanwhile i learned, that's - at least per default - only possible with textfields or textarea fields, but not with repeaters, table, pagetable, image, file field types. For "complex" field types you have always a modal layer for frontend editing. And the modal layer displays the backend/admin ui edit-view of the field, not wysiwyg / not the page layout. So to achieve INLINE WYSIWYG frontend editing with CRUD + DRAG functionality, i have to invest quite a bit of hacking - without much knowledge of AJAX, which in turn would almost be necessary to not have page reloads all the time and to resemble the old edit experience... My customers are accustomed to edit / add / delete and drag data rows/ table rows directly inline wysiwyg and want to retain their edit-experience. But meanwhile, if i see e.g. the demo video of the Profield table field, the backend edit view is really very clear and unbloated. Repeaters are a bit more bloated and scale perhaps not so good as table fields. Perhaps i can convince my customers to go this route. And the table field should be accessible to frontend editing the same way as repeaters or pagetable fields do, i assume?
  13. wow @bernhard. Thanks. Thats a good start. As for Ajax. Yes, of course i'd like to do the actions without page reloading. Hm, could you point me to a good tut or resource? I haven't enough knowledge how to interact with PW if i want to implement actions the AJAX way...
  14. the item numbering is actually the dish position number: like Nr 71 | fried chicken | 7,90 like in these chinese cards edit: Maybe it's indeed better to do the numbering automatically, i agree. The customer said, that he wants to edit the number, but i don't remember at the moment, why...- i defiinitely will clarify this. It really seems to me, that pagetable is the option to go for me. Thanks for clarification. Regarding implementing at least add / delete items in inline editing: @bernhard could you point me to some good resources, where i could learn how to accomplish this? - Really thanks for your engagement !
  15. hi @bernhard, as for implementing an ajax request: Don't know how to accomplish that, never did this before...wait, no, recalling one incident implementing a registration form with ajax, it was a terrible experience... never got it really working, XAJAX comes to my rescue at that time ... Regarding the pagetable field for FE: But wouldn't a Repeater work for FE too, if i understand the posts above correctly? Or do you think a pagetable field is a better fit for a special reason?