Jump to content

Lenz

Members
  • Posts

    38
  • Joined

  • Last visited

Everything posted by Lenz

  1. That seems to be a game changer. Congrats on this effort. Keep it up!
  2. +1 Absolu +1 and i'd suggest the blue one!
  3. the community here is second to none. Never experienced such a combination of Knowledge and Kindness.
  4. Thanks for posting. This is exactly the kind of information which should be displayed centrally and not scattered around various places...
  5. +1 for explanations of the numerous variants of $pages / pages() / $this->pages..or when do i have to use "wire" etc --- generally explain the different methods of variable instantiation, scope, when where, why, differences ... with bringing the mostly used / recommended method on first place. +1 for a codepen like playground / console for a API demo a module installer as described above would be great!
  6. ok, @adrian your points make sense. Then there's only one solution: Adrian has to become part of the core ?
  7. Congrats on the launch! The whole site looks much more modern and to the point now! Respect for putting in this much effort in such a short amount of time! I second the suggestion of showing a video or a slideshow of images without the imac frame on the starting page. The frame indeed distracts the user from the valuable content imho and steals important space for displaying the actual features of PW. Also a display of a console where the output of API calls is displayed could be a game changer in terms of a pro PW decision for developers. I think Tracy Debugger should be part of the core. In my eyes this is one of the most valuable developing tools if working with Processwire.
  8. On Linux (MX Linux) Firefox 64 / Google Chrome 71.0.3578.98 all is looking fine, like in the screenshot posted by @breezer
  9. aha, now it's clear. @ryan Thanks a lot for clarifying this. Also thanks for the hint @fbg13
  10. 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.
  11. 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...?
  12. 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...
  13. Hello @abdus, congrats on your really great venture. Much appreciated. Is there any news about your newsletter module?
  14. @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.
  15. 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.
  16. wow congrats on this hell of an achievement, also demonstrating the power of processwire as an app development framework.
  17. 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.
  18. 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?
  19. @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?
  20. 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...
  21. 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 !
  22. 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?
  23. 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)
  24. 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?
×
×
  • Create New...