Jump to content

netcarver

PW-Moderators
  • Posts

    2,001
  • Joined

  • Last visited

  • Days Won

    42

netcarver last won the day on July 14 2021

netcarver had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    UK

Recent Profile Visitors

15,896 profile views

netcarver's Achievements

Hero Member

Hero Member (6/6)

2.9k

Reputation

18

Community Answers

  1. Looks like there's something wrong to me. The documentation says findJoin() returns a PageArray - but you are getting a string (with embedded null bytes too).
  2. Not sure how rockshell works, but I find SSH's config file very helpful. Perhaps something like this in ~/.ssh/config this could help here (if not already in use)? Host * IdentitiesOnly=yes Host staging IdentityFile ~/.ssh/<YOUR STAGING KEY FILE> #User bernhard ## Uncomment and change if server account doesn't match your local name #Port 22 ## Uncomment and change if server not listening on port 22 Any time an ssh connection is attempted to staging, it should use the correct identity file (or files if you add more IdentityFile lines,) rather than have SSH try all your keyfiles until the server complains.
  3. I might be misunderstanding, but couldn't you do this in the base template...? <?php if ($page->id == 1044 || $page->parent->id == 1044): ?>
  4. If you know the parent page you can iterate over all the children very easily, even passing in a selector with your mengtest condition. You could try... echo "<ul>"; foreach($page->children('mengtest=...') as $child) { echo "<li><a href='$child->url'>$child->title</a></li>"; } echo "</ul>"; Docs: https://processwire.com/api/ref/page/children/
  5. Well, late to the party, having been a long-time user of devilbox for local docker-based development. However, the need to support distinct per-project tech stack differences has forced a move away from devilbox to ddev and, apart from the need to make a few local .env changes, it's working out really well so far. Highly recommend it if you haven't tried it out yet.
  6. Hi @bernhard, yes that was my migrate.php file. Does not seem to add anything to templates no matter what I do with it, including removing the strict declaration, though creating fields and templates seems to work (just not adding fields to templates.) I'll try using an older version of the module.
  7. I'm also seeing a lot of fake pages in the trash that seem to be generated by RockMigrations, despite my test file having nothing to do with either the pages or fields in the migrations.php file. For example...
  8. Hi @bernhard, just starting to try out your module and am having a little trouble. I've added this file to my /site/ directory and was expecting to the a new rmdemo field and template - with the rmdemo field added to the template. Both the field and the template are created fine when I reload the modules - but the rmdemo field is not added to the rmdemo template. Am I missing something? <?php declare(strict_types=1); namespace ProcessWire; /** @var RockMigrations $rm */ $rm = $this->wire->modules->get("RockMigrations"); bd('Create field + template via RM'); $rm->createField('rmdemo', 'text', [ 'label' => 'My RM Demo Field', 'tags' => 'RMDemo', ]); $rm->createTemplate('rmdemo', [ 'fields' => [ 'title', 'rmdemo', ], 'tags' => 'RMDemo', ]);
  9. @teppo, that might work if we combine it with an idea from @adrian. If we set a high initial value for ids (say 1 million) and allow pages using the user template(s) to use these independent autoincrement IDs at whatever rate the users sign-up at. We could try using our own, sub-1,000,000 counter value when adding pages with any other template. There won't be that many of them and we going to share these pages amongst all the installations anyway.
  10. Hi @DaveP, thanks for the idea. Hadn't thought of that - but I think it will become difficult to pull off, especially if we extend to other regions and have to sync 3 or 4 (or more) installations.
  11. I'm working with a client that uses PW to provide the basis for various services, and GDPR/legalities mean that the data for our EU-based users has to live on an EU-resident server. Similarly, US-sourced data has to live on US-resident servers. As the sign-up rates are different in each region, the page IDs between the sites quickly get out of sync, so when new features involving pages are added to the US and EU sites, the IDs of the pages housing new options/blog posts etc are out of sync between them - making references to the pages in the code-base using the page ids impossible. The only thing causing the desynchronisation between the installs is the user pages. I know we can use different programmatic techniques to reference these feature/structural pages, but I'm curious; is it possible to force users (any page using the user template - or any alternative user template) to use a separate auto-incrementing id in PW? I don't think so, but if it could be done, how would you approach this? Being able to have fixed ids for landmark pages, despite differing sign up rates across regions, would be handy.
  12. The newer versions of symfony/yaml require a pretty recent version of PHP - so you might need to use an older version of that library if you do go down that route. If you don't need Yaml support, then removing it might be better.
×
×
  • Create New...