Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/14/2024 in all areas

  1. @wbmnfktr The ecosystem of available packages and services is definitely one of the major draws of Laravel. It almost parallels the Wordpress ecosystem, but ten times more professional. A lot of Laravel packages are very high quality, actively maintained, well tested, etc. That's probably a result of their somewhat "enterprisey" approach to structuring a project. Dependency injection, containers, service providers, those are all great approaches for professional projects, but they do require some commitment to learning these specific concepts. ProcessWire's approach to extension via hooking is almost the complete opposite of Laravel's container resolution approach. They're both flexible and ergonomic, but ProcessWire's a lot more approachable and easier to grok for newcomers I think. Being able to replace an internal handler in three lines without copy-pasting the whole class is really magical.
    1 point
  2. As I look at Laravel, and quite often stumble across YouTube videos about it, these days I asked myself... is there something that Laravel does (way better) that ProcessWire should/could/has to do as well? Things I find super interesting are those Breeze, Intertia, Volt, Livewire starters. Amazing! Or the Laravel Queues, those various database adapters to use SQLite or Postgres just by changing a line in the config. The Tailwind/Vite workflows, and things like that. Not to mention all those on-demand services. It's impressive! But sure, those are big and heavy things you can't just copy, but there is a reason people love Laravel. I know some of us here are actively using tools like Laravel and CraftCMS. Why? Both are super complicated right from the start aka installation. (yeah, I love to move around files and use my ZIPs to extract them into other folders and go from there!).
    1 point
  3. @flydev I am receiving a General error: 1273 Unknown collation: 'utf8mb4_0900_ai_ci' error when trying to migrate a PW site from a production/staging server back to local dev with MAMP on macOS. Is this a MySQL version error? And if so how do I fix ? also getting this message which I have never seen in Duplicator just before inputting database name user/pass and extracting Deprecated: strrpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in /Applications/MAMP/htdocs/production-pulldown/installer.php on line 709 - - - SOLUTION - - - I found a solution to my problem. I had to edit the .sql file within the duplicator-temp directory and do a search/replace all instances of utf8mb4_0900_ai_ci with utf8mb4_unicode_ci That seemed to have solved the issue. Never had that happen before. Must be an incompatibility with the duplicator package generated on the staging server and my local dev setup.
    1 point
  4. @François Lacruche you can read more about permissions in the post I linked before and security here: https://processwire.com/docs/security/ By doing `chmod -R og+rw site/assets` you added read and write permissions to `others` and `group`. The recommendation is: 0755 for directories: 7: Owner (full control: read, write, execute) 5: Group (read and execute) 5: Others (read and execute) 0644 for static files: 7: Owner: Read and write permissions (rw-) 4: Group: Read permissions (r--) 4: Others: Read permissions (r--) So just to be sure, you can execute: `chmod 755 site/assets/` (permissions for directory) and then `find site/assets/ -type f -exec chmod 644 {} \;` (permissions for files)
    1 point
  5. The main benefit of this thread is that I finally have a space to post in PW forums. I have this internal desire of being super active here, but as a forever-noob developer I can't participate in others people's topics. So, this post suits me hahaha. I have a secret: The infinite site hosting scheme. The only word in marketing that's more 'scheme' than 'scheme' is infinite. And when they combine infinite and secret, you can know you've officially landed in the Promised Land.
    1 point
  6. I've created a custom alias: So all I have to do is type "ddc" and hit enter
    1 point
  7. I've been wanting to review the 5 pages of responses and summarize the findings, but what I will say before (if?) I get to that: There seems to be three primary audiences that PW is catering to, or that it can potentially cater to: Developers (ease of development, API, headless, documentation, module development/sales, etc) Clients (security, continuously developed, version stability, availability of developers) Consumers: A developer and client all in one (all the ways in which it competes, and how it's different) It may not be evidently clear what the project is primarily aimed at catering to, and perhaps that needs to be clarified, whether directly by Ryan in terms of what he is interested/able in supporting, or by the community's desire (as Ryan seems amicable to our opinions on steering it). That may also help guide any potential website redesigns. I think this is an important question to really consider and have answered. Although it can be done, it's really hard to properly target all three of the above, all at once.
    1 point
  8. We are live and have a very special guest in the video ???
    1 point
  9. It seems that the user needs to have the page-edit permission for both the parent page and the child page in order to sort the child page. I hadn't noticed this before. It's a shame that the page-sort permission can't be granted independently of page-edit as it seems like they involve quite different levels of risk/responsibility. I opened a request at GitHub: https://github.com/processwire/processwire-requests/issues/290 As for a hook you could use this in/site/ready.php: // Just for your target role if($user->hasRole('editor')) { $wire->addHookAfter('ProcessPageEdit::execute', function(HookEvent $event) { /* @var ProcessPageEdit $ppe */ $ppe = $event->object; $page = $ppe->getPage(); // The names of templates that the user is not allowed to edit $disallowed_templates = ['colours', 'colour']; if(in_array($page->template->name, $disallowed_templates)) { // Replace the Page Edit markup $event->return = 'You do not have permission to edit this page.'; } }); } This may not be 100% secure in that a person could theoretically create their own edit form in their browser dev tools (although I think that's a very unlikely possibility). But if you wanted to be extra safe you could follow an alternative approach of limiting access at the field level for all the fields in the relevant templates. Depending on the number of fields that could be a hassle via the admin interface so you could look into doing it via the API.
    1 point
×
×
  • Create New...