Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/09/2022 in all areas

  1. Natasha Marques is a desserts chef and chocolatier from Brazil with an international carreer. Now established in my hometown Porto, she's about to open a shop and already shipping her premium line of sweets and desserts. The website is my usual combo of PW with StencilJS frontend with a content blocks approach. Minimal stack of modules: SeoMaestro, WireMailSmtp, and my own block selector module which is a hacked version of FieldSelectFile. The site is only in portuguese, but have a look anyway: https://arbynatashamarques.com/
    6 points
  2. Just in case... have a look a Git worktrees. Sounds weird and complicated (especially in the setup process) yet... it could be another game changer. No stashing, deleting or workflows like the workflow from xkcd. Maybe even easier than branches to be honest, while still using branches. I keep this here... as it's entertaining and fun... Looking through that channel you might find interesting things while searching for "git" or "workflow" or "bug". Sure it's VIM-based, yet even possible in VSCode (and others) I guess - most of the time. However it's super fun to watch and to get ideas and insights.
    2 points
  3. Excited to be learning REACT/NextJS. It's so 'on-trend'. I can double my hourly rate, take 3x as long to deliver a website with 2/3 of the Google Lighthouse results and who doesn't love the spinner while the component content loads? Doing a well optimised PW site with minimal JS, fast page loads, accessibility, SEO and more built in is so old hat. And even better, with JS frontends, the code maintenance goes on and on. No end to revenue possibilities. FML
    1 point
  4. Thank you @Robin S $page->id was the thing I needed ?
    1 point
  5. Not sure I understand the question, but if you have a Page object (e.g. $page, $my_page) and you want to match it to a Page Reference field in a selector string the best way is to match by the page's ID. my_page_reference_field=$page->id Or you can actually just do... my_page_reference_field=$page ...because a Page object becomes an ID when it is treated as a string. Similarly a PageArray will become a pipe-separated string of IDs that can also be used directly in a selector string: my_page_reference_field=$my_page_array
    1 point
  6. @ErikMH Thanks for the additional info. I'm not yet sure what the issue could be, as I also use custom page classes here, but I I think by getting yours working we might find closer where to look. And I think to do that, some additional checks are needed in your code, which I'll try to describe below. The error message you've got appearing (that there is no getTitle method on NullPage) is a valid error message, as it is true that NullPage has no getTitle() method. NullPage is a valid return value from any Page method that can return a Page object. So we know at least that there is a line of code somewhere that is calling a getTitle() method before checking if it has a Page that would have that method. You can check for a NullPage by: if($p instanceof NullPage) { ... } or more commonly you can do: if(!$p->id) { ... }. That works because NullPage objects have an id of 0. In the debug backtrace we can see that home.php line 95 calls IssuePage::getEntry(). And then IssuePage.php line 43 is likely making a call that is returning a NullPage. I would add a NullPage check before calling getEntry() (home.php line 95) and then another on IssuePage line 43. That should prevent the error from occurring, and is something you'd want to have whether you were seeing this error in the first place or not. And by identifying specifically what change seems to fix the issue, that should point us in the direction of what method call might be returning something potentially incorrect (since you indicated it worked in earlier versions but not in the current). Once you identify the culprit, it would be helpful for us to know what that condition is where it's coming across the unexpected NullPage. So let's say $p is the page you are calling something on (like your getTitle), you might do something like this: $title = ''; if($p->id) { if(method_exists($p, 'getTitle')) { $title = $p->getTitle(); } else { bd("Page $p has no getTitle method (called from page $this)"); } } else { bd("Unexpected NullPage received in page $this"); }
    1 point
  7. Hello Mate, a while back I've made a video on how I usually approach usage of Tailwind with Pw, you can find it here. Nowaday, with Tailwind v.3.x I've changed my approach slightly, since some additional postcss packages are already included. Below my updated package.json file, in order to better understand which scripts I invoke: { "devDependencies": { "cross-env": "^7.0.2", "cssnano": "^4.1.10", "laravel-mix": "^6.0.41", "postcss": "^8.4.5", "postcss-import": "^14.0.2", "postcss-preset-env": "^7.2.3", "tailwindcss": "^3.0.18" }, "dependencies": { "concurrently": "^7.0.0", "postcss-cli": "^9.1.0" }, "scripts": { "start": "npx tailwindcss build -i styles/entry.pcss -o styles/dist/dist.css", "watch": "concurrently \"npx postcss styles/entry.pcss -o styles/dist/dist.css --watch\" \" npx mix watch \"", "build": "concurrently \"cross-env NODE_ENV=production npx postcss styles/entry.pcss -o styles/dist/dist.css\" \"npx mix --production\"" } } Basically I rely on tailwindcss cli to kickoff the first compilation of my entry point, then I invoke postcss --watch and mix watch (for js). At build time I switch node environment to production (which cssnano the final css) and mix --production to finalize my js (minification, module resolving, etc.). For completion here is the postcss.config.js: const cssnano = require('cssnano'); module.exports = () => ({ plugins: [ require('postcss-import'), require('tailwindcss/nesting'), require('tailwindcss'), require('autoprefixer'), require('postcss-preset-env')({ features: { 'nesting-rules': false } }), ...(process.env.NODE_ENV === 'production' ? [cssnano] : []) ] });
    1 point
  8. Hello Bernhard, today officially FontAwesome 6.0.0 came out. The metadata that RockAwesome is built on is no longer included. I have integrated the new GraphQL interface locally into the module to search for icons. Would you be interested in adding it directly to RockAwesome? The interface is accessed directly from JS. ciao Sebastian
    1 point
  9. Hello everyone! A update to the new ProcessWire version 3.0.184 and the new PHP version solved the issue for me. Thanks again! ?
    1 point
  10. Great! ? OMG, when reading your last answer, I finally got that GIT is used (responsible) for the merging-magic. Ok, that makes it look to me in another light. ?️ The whole time I assumed that there (at least additionally) must be some sort of importer in the CMS which has to deal with all the heavy stuff (conflicts and edge cases, etc). But now, its all good. ?
    1 point
  11. Yeah, the migration guide looks pretty daunting. In that case I prefer leaving it as-is for now. If you find a simple fix, let me know and I'll happily review/merge any input.
    1 point
  12. @flydev ?? Thanks, I appreciate that. I will look into this.
    1 point
  13. First, thank you very much, @ryan, for your code pointers. I’m not sure how I’d fallen into the habit of $me = wired($this);, but my custom-class code was riddled with it. I removed it all, and changed all references to ->parent properties to ->parent() method calls. On 3.0.184, this sped up most page loading by about 10% (hooray!), but had no other discernible effect. It’s a testament to ProcessWire’s efficiency that I haven’t ever felt the urge to go hunting for speed improvements.... Anyway, I then attempted to upgrade to 3.0.193 — and immediately was presented with NullPage errors. So I tried 3.0.189, which ran fine. So too did 3.0.191. I was becoming pretty sure the problem was going to be introduced with 3.0.193, but I tried 3.0.192 — and boom! So, this is code that I’ve been running in production without incident since last June, but 3.0.192 is causing major difficulties, which continue with 3.0.193. I don’t see anything wrong with my code (but, then again, I’m the guy who put $me = wired($this) into all his custom classes). I’ve looked at the descriptions of everything between 3.0.191 and 3.0.192 on GitHub, but nothing stands out as related. It’s late here now, so I’ll write up a summary of the logic that’s causing the problem tomorrow morning, but essentially a custom class method is called, correctly, and it’s now failing to run — giving an error that the method isn’t callable because the object is null. But it’s not null — and I get exactly the (non-null) results I expect up through 3.0.191. Here’s a link to 3.0.192 on GitHub. I’d be very grateful if anyone can give me further guidance (or figure out which bit of 3.0.192 is responsible). I’ll post more details in about 12 hours. [administrivia: Clearly, therefore, this problem doesn’t belong in this thread; I’d be happy if someone could split it out and put it somewhere appropriate.]
    1 point
  14. @kongondo It could but I would guess your bottleneck is quantity of pages, not fields or templates (?). So unless you literally mean hundreds-of-repeater-fields, for your case I think you'd want to enable the ajax loading features of the repeater (if not already) as that would make a big difference. It was a one-off thing that I used and deleted. Writing in the browser so it may need adjustment, but here's something similar (though a bit simpler than what I used): $fieldtype = $modules->get('FieldtypeText'); $title = $fields->get('title'); for($n = 0; $n < 1000; $n++) { $field = new Field(); $field->type = $fieldtype; $field->name = "test_$n"; $field->label = "Test field $n"; $fields->save($field); $fieldgroup = new Fieldgroup(); $fieldgroup->name = "test-$n"; $fieldgroup->add($title); $fieldgroup->add($field); $fieldgroups->save($fieldgroup); $template = new Template(); $template->name = "test-$n"; $template->label = "Test template $n"; $template->fieldgroup = $fieldgroup; $templates->save($template); } @ErikMH I'm not aware of any recent changes that would affect pages in that manner. But for your code, I would drop the $me = wire($this); there is no $me, there is only $this. ? And rather than referring to $me->parent; refer to $this->parent(); with the parenthesis, so that it is a method call rather than a direct access property. Since you are "inside" of the Page class here, the interface is a little lower level than if you are outside of it. Usually it doesn't matter but in this case of things like "parent" I think it might be safer to method calls rather than properties, because these things are dynamically loaded and so accessing the method ensures that happens.
    1 point
  15. @horst Well then, allow me to raise your expectations again, because your description is not how it works ? In your scenario, both developers could merge their branches with zero conflicts, and as a result the main branch would incorporate all the changes from both branches. They don't even need to know what the other one is doing, and nobody needs to constantly keep up with changes from other branches / team members. That's because git is really smart in the way it performs merges. Basically, you can view every branch as a set of changes applied to the existing files. As long as those changes don't conflict, you can merge in multiple PRs back to back without any manual conflict resolution. So most of the time, you can just lean back and everything works. The only time you get a merge conflict that needs to be resolved is if there are actual conflicts that require a decision. For example, if developer A renames some_old_field to unicorns and developer B renames the same field to rainbows, that would result in a merge conflict, because a single field can't have multiple names. So someone needs to decide between unicorns and rainbows for the field name. In other words, you don't have any overhead caused by git itself – git acts as a safety net by warning you about merge conflicts so you can fix them. In a well-engineered system with good separation of concerns, it's rare to have non-trivial merge conflicts, since it's unlikely that two people working on separate features will need to touch the exact same files. And most of the time, if you do get a merge conflict it's trivial to resolve – for example, if two PRs add a new variable to our SCSS variables in the same place. This would be a merge conflicts, but it's trivial to resolve, since you know you want both changes. If you know git well, you can resolve those in under a minute, oftentimes with a single command (by specifying the appropriate merge strategy for the situation). It's the exact opposite – the larger the development team, the more you will benefit from this streamlined workflow. Everyone can focus on different features and merge their work in with the minimum amount of effort required by either them or other developers to keep in sync with each other. Regarding all the git stuff, I recommend the Git Pro book (available for free), a great resource to understanding how git works under the hood and discover some of the lesser-known features and power tools. Reading the book front to back helped me a lot to establish our feature-branch workflow (for Craft projects) at work, utilize git to work way more effectively, solve issues with simple commands instead of the xkcd 1597 route and much more. For branching and merging in particular, check out the following chapters: 3.2 Git Branching - Basic Branching and Merging 7.8 Git Tools - Advanced Merging
    1 point
  16. +1001 ? And my first request is, to start with TDD (Test Driven Development)! I can share the basics (or a starting point) for that, means I've a small and comfortable to use setup ready for that. Would need to write a short documentation / explanation, on how it works and should be used. +1 ? -10 ?
    1 point
  17. https://github.com/wanze/ProcessGoogleAnalytics
    1 point
  18. @Simi I have the same situation when using PHP 7.4. And no configurations and folder permissions fix this. When using PHP 7.3 (and earlier) modules are loaded normally.
    1 point
  19. Hi! Had this problem today too. In my case this was a problem with file permissions. After setting permissions to 777 for the folder site/modules/ it worked.
    1 point
  20. Hi, based on the work of @microcipcip and @gebeer (see their posts here and here), I put together a Processwire + React boilerplate (profile). Github repo: https://github.com/lapico/process-react Cheers, K
    1 point
  21. tells user.restart browser ? try disable csrf if no fix /site/config.php u try $config->protectCSRF=false; gazley dark, beard.looking good keep working.at it too
    1 point
×
×
  • Create New...