Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


gebeer last won the day on January 19

gebeer had the most liked content!

1 Follower

Profile Information

  • Gender
  • Location

Recent Profile Visitors

10,858 profile views

gebeer's Achievements

Hero Member

Hero Member (6/6)




Community Answers

  1. This can all be achieved by code which means that you can put this in a migration function. And in RockMigrations you call your migration function on the target installation. RM is supporting Repeater Fields. So even the 3rd scenario would be possible.
  2. Thank you for summing this topic up in a new thread. I had the same intention but couldn't spare the time. I am all for version control of fields and templates. @bernhard's RockMigration Module already does a great job here. And since he introduced the prototype recorder I am very excited that we will soon have something to work with and build upon. This should really be part of the PW core or available as optional core module. Would be great if @ryan put this on the roadmap for 2022.
  3. @ryanThis is a bit off topic, but I would also support version control for fields/templates as something to maybe concentrate on for this year. There is a lively discussion going on: And Bernhard has already shown an awesome proof of concept in his video:
  4. I am more excited about the recorder than about YAML. And I see your point. When using a PHP array for the migrate() method, you can do things that you can't do in YAML. But on the other hand, for recording changes locally and than migrating them to staging/live, YAML would be sufficient. Your use case, where you setup fields and templates for a RockMails module with RockMigrations is different. When installing that module, it needs to check whether it is being installed on a multilang site or not. But when recording and migrating changes, we already know the context for the migration since it has been recorded through YAML. My conclusion would be to store the recorded data in YAML or JSON. For other use cases, like you described, we can still use a PHP array.
  5. I think I had a wrong understanding of the migrate([]) method, thinking it is destructive for fields/templates that are not in the $config array. So if I have an existing site, I would have to build the $config array with all fields and templates that are in the existing installation already. If I forgot one field, it would be deleted by the next call of the migrate method. But looking at the code, I see that it only creates fields and templates. But still, if I don't add fields/templates to the $config array, that are already there in an existing installation, the migration would not cover all fields/templates. Does that make sense? Yes, this is exactly what happens in the video. All fields/templates of a site are getting written to the yaml file. It would be great, if we had this available for setting up initial migration() $config arrays. Either inside the module or as a separate "recorder" module. That way, we could plugin RockMigrations to any existing site, create the initial $config data (inside a yaml file) and move on from there with our migrations.
  6. Hi @bernhard shows a test of recording changes in templates/fields to yaml. This looks very promising. Do you have any plans integrating this into your module? It is easy to use RockMigrations when you start a new project. But for existing projects where RM comes in later, we need to write the migration files by hand before we can start using rm()->migrate. Would it be possible to create a yaml from all templates/fields of an existing install based on the recorder that you showed in that video?
  7. This is totally freaking awesome! Can't give enough thumbs up. Any plans to release this? Wannahave 🙂 That would just be such a great help for keeping things in sync.
  8. I published a generic module with some examples at https://github.com/gebeer/CustomPageTypes Happy visual learning 🙂
  9. Hello all, Since https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/ came out, I used to implement custom page classes as modules, following the principles described in that tutorial. Now only a few weeks ago I stumbled across https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes. This seems to me a much cleaner and easier way of implementation. Though it restricts the naming of custom classes to the naming conventions for the class loader. Other than that I can't really see any more disadvantages. Which way do you prefer and why? On a side note, useful features like described in the second link often can only be found in @ryans core update blog posts. If you don't read them on a regular basis, those new features are easy to miss. I'd love to see those hidden gems find their way into the API reference in more detail. Although $config->usePageClasses is documented at https://processwire.com/api/ref/config/, I think it would deserve its own page with all the explanations from the blog post.
  10. Developing on Linux (currently Arch/KDE Plasma) for the last 16 years. Would never go back to proprietary alternatives. Why pay for something that should really be free for all? Devtools: Editor: VSCodium with PHP Intelephense, GitLense, PHP Debug (xdebug support), Prettier (Code Formatter), Todo Tree and @bernhards PWSnippets. Local dev env: after having used vagrant for a long time, about 4 years ago I switched to https://laradock.io/ for local docker environment. Ensures portable environments across multiple machines PW modules used on almost every project: TracyDebugger, WireMailSmtp, ProFields (mainly for Repeater Matrix), TablePro Asset building pipeline: npm scripts / gulp / webpack. Will have a look into Laravel Mix. Might save time although I actually like to fiddle with all the configs. Deployment: for older and ongoing projects mostly SFTP. For new projects git with git hooks. This is so much cleaner. Not using any service but creating own git hooks on the server. git must be available on the production server. Staging servers used rarely. Mostly deploy from local to production. Hosting: I do not offer hosting services. This is up to the client. Personally I use https://uberspace.de/en/ which is a command line configured shared hosting provider from DE with a pay what you want pricing model
  11. Thank you so much for this post. This should be considered for the official documentation. It would have saved me a lot of time and headache when developing my first custom fieldtype
  12. UPDATE: I installed a multilang page from scratch and found that the behaviour is the same as with my other install which also is latest dev. On PW 3.0.189 dev mysite.local/cn/cn/ redirects to mysite.local/cn/ Whereas when I switch to 3.0.184 master, mysite.local/cn/cn/ throws a 404. Will go and file an issue. Meanwhile if any of you can enlighten me, that would be great. Filed an issue at GH https://github.com/processwire/processwire-issues/issues/1479
  13. Thank you for taking your time. The apache rewrite option will be the last resort if I cannot get PW to behave the way I would expect.
  14. Hello all, didn't know how to better describe my problem in the thread title. So bare with me. Will try to explain my setup. - multilingual site with all necessary modules installed, including LanguageSupportPageNames - default lang is English. Default lang homepage URL performs a redirect to /en/. So default home URL is mysite.local/en/ - one of my languages is Chinese (name cn). Home URL for Chinese is mysite.local/cn/ Page tree with page names and URLs for chinese language: - home: mysite.local/cn/ -- cn: mysite.local/cn/cn/ << here is the problematic URL: page name = lang name --- page1 mysite.local/cn/cn/page1 (only active in en and cn) --- page2 mysite.local/cn/cn/page2 (only active in en and cn) Now if I visit mysite.local/cn/cn/ I get redirected to mysite.local/cn/ which results in homepage view. Visiting mysite.local/cn/cn/page1 redirects to mysite.local/cn/page1. Results in 404 Changing the page name 'cn' to something else like 'asia' would resolve the problem But it is not an option because the URL structure like /en/cn/ and /cn/cn/ is a requirement for the project. Tracing back the redirect with Debug::backtrace inside a before hook to Session::redirect reveals the following: In wire/core/PagesPathFinder.php l. 519 the array $parts, (in my case [0 => 'cn', 1 => 'cn']) is passed by reference to getPathPartsLanguage(array &$parts) In that method the language is determined from the first entry in the array $parts. In that process the first entry is removed by $segment = array_shift($parts) Since $parts is passed in by reference, the original array of 2 path elements is being reduced to 1. This results in a wrong path and redirection. When I change the code so that $parts is not being passed by reference, weird things start happening. Getting 404s for existing pages like mysite.local/cn/cn/page1 and even for default language mysite.local/en/cn/page1 ATM I'm lost and don't know how I can get the required URL structure to work as expected. So if any of you have an idea of what could be the culprit here, please let me know. Thank you for staying with me until here.
  15. Totally did not think of that one. Thanks a ton!
  • Create New...