• Content count

  • Joined

  • Last visited

Community Reputation

11 Good

About Lenz

  • Rank
    Jr. Member

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

346 profile views
  1. @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.
  2. 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.
  3. wow congrats on this hell of an achievement, also demonstrating the power of processwire as an app development framework.
  4. 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.
  5. 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?
  6. @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?
  7. 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...
  8. 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 !
  9. 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?
  10. Thanks a lot @Robin S @tpr @bernhard for your valuable input. I have a few remaining questions Does this mean, that i can only edit Repeater items in inline mode and that i haven't CRUD functionality available in inline edit mode? Meaning, i can't add a new repeater, delete a repeater or drag a repeater to a new position? (see my example with the menu card, where every line/dish would be represented with a repeater ) @bernhard Actually nothing is bad about the Admin UI, if you ask me. It looks even good. But unfortunately my clients are accustomed to edit directly inline wysiwyg and don't want to give up this experience... @all: Let's say if i could convince my customers so they accept FE within Processwire as it is: Do you think that regarding my use case (see my first post) a repeater would do the job perfectly fine or has a Profield like "table" maybe advantages over a Repeater? Meaning, if i have 4 simple textfield wrapped in a Repeater vs wrapped in a Profield table field: Are these 2 scenarios essentially behave the same or are there differences? There are round about 100 - 150 entries in the menu card (inclusive beverage)
  11. Thanks @tpr for your answer. Good job! As i can see in your example: The frontend editing is only possible with a modal layer here? Or precisely could the modal layer display the edited page wysiwyg instead of their backend view? I mean with the build in frontend editor: Is it possible to edit repeaters or table fields directly inline without a modal layer or with a modal layer displaying the page wysiwyg? If so, would i also have CRUD functionality and drag&drop available?
  12. Hello all, i have a question regarding the following scenario: My customer wants to edit a menu card of a restaurant website directly in the frontend. Each dish / menu is displayed in a row with 4 simple textfields (position nmbr, name, quantity (optional, for drinks) , price). My customer preferably not only wishes to edit/update existing fields/rows, but also add a new one, delete one, or move an existing one up or down to a new position in the card. Would these actions be possible per default in the frontend edit mode, if i'd have e.g. a table profield storing the 4 textfields per dish? Or is this only functional in the backend? In a demo video of a Profield (-> fieldtype table) i saw the requested edit functionality (edit or add a row of fields, drag a row up/down, delete a row, safe) in the backend... Btw., regarding this concrete use case of a menu card: Would i have to use at all a Profield like table or could i accomplish the task also with a Repeater Field or a Pagetable fieldtype? In any case at least i don't want to let my customer mess around with a richtext field / inserting a table within CKEditor in the backend... Maybe there are better approaches than the above mentioned. Edit: I should add, that the site is a static one, equipped with an meanwhile dysfunctional inline frontend editor (that had the capabilitiy of editing, moving, deleting such rows directly inline in the frontend). Now i want to replace this editor with processwire. Thanks in advance
  13. @abdus thank you very much. That did the trick. I put the values (-> en_US.UTF8 ) without quotation marks in the translation field. Also i saw that there was already a string for the german language (-> de_DE), which i left untouched, but now i think it would be better to change it to de_DE.UTF-8 ... Anyway i strongly suggest to change the warning messsage to exactly the line you wrote me in your post, because that's clear and easy to grasp, imho. ok on hindsight - if one has a multilanguage installation - one should know what is meant by "please translate the C locale...", but still, i managed to misunderstand the original message whereas your line is 100% clear.
  14. Hello, i was upgrding to PW new master (3.0.61) from old master (3.0.42) and recieved the following warning (have a multilanguage installation -> german and english): Warning: your server locale is undefined and may cause issues. Please translate the “C” locale setting for each language to the proper locale in /wire/modules/LanguageSupport/LanguageSupport.module (shortcuts provided below): • English • German For example, the locale setting for US English might be: en_US.UTF-8* 1. Where exactly in the file LanguageSupport.module (which has some 900 loc) do i translate the C locale setting? - I couldn't find such a setting in this file... 2. Isn't it a bad idea to make changes to a core file, that normally should be overwritten by the next upgrade? Or do i miss something? Thanks in advance.
  15. very interesting discussion here. @LostKobrakai: If you don't mind, could you elaborate a bit more in detail why this new template strategy could be misunderstood or confused with a template engine? I really don't get the point, but would like to. To my - admittedly rudimentary - knowledge a template engine like twig adds only a little bit syntactic sugar like {{ var }} or something like {% block content %} Content of the page... {% endblock %} But what has this to do with the template strategy Ryan introduced here? And i also fail to understand in which regard the new template strategy could potentially lead to a tight coupling of markup with api stuff? I mean isn't the separation of business logic and view completely independent of using an engine like twig or not? Or in other words: Couldn't you mix up markup and business logic as easily with twig as wihtout it? Or again in other words couldn't you use the MVC pattern as easily with Ryans new template strategy as without it? (-> would like to know more about how to use MVC within PW templating btw...) just curious...