Leaderboard

I'll share a bit of a sidenote on the language overall that I think may start to appeal to developers again who are giving PHP a try with or without a framework. PHP 8.0-8.2 has changed the way I write code significantly and features new and old like arrow functions, enums, union typed properties, nullsafe operators, named arguments, return type hinting, constructor property promotion, etc. are fantastic. Performance gains keep rolling in as well. I've enjoyed seeing the deprecations and cleanup in the language- even just committing to using typed properties and return type hinting make so much of a difference in how the language feels. I like the first video above where the person focuses on how enjoyable it can be and I'm always hesitant to give much weight to a JS developer who has some really outdated opinions. For example, these two sets of code do the exact same thing: I think that says a lot and the new features and style of the language are going to continue to boost frameworks as they adopt them as norms. Developers returning to PHP or trying for the first time are going to see something that feels really new. I've been building a Laravel/Vue application and InertiaJS feels like magic the way it marries the SPA front end with the back end. Really enjoyable.

Just something I stumbled across and noticed the last few days/weeks. More and more Devs (mostly from the JS-sphere) are talking about PHP, and not only about the latest JS framework trends. There is a downside as they are talking about Laravel most of the time, yet it's something I didn't expect.

@olafgleba As I understand it, you've got pages that live at /members/blog/<name> and you want them to be accessible at /blog/<name>. First thing is to make it so that the blog post pages ->url property reflects the URL you want them to use. You can do this with a hook in /site/init.php: $wire->addHookAfter('Page::path', function($event) { $path = $event->return; if(strpos($path, '/members/blog/') !== 0) return; $event->return = str_replace('/members/', '/', $path); }); Next, you want to make it so that ProcessWire will deliver those blog post pages at the /blog/<name> URL. You can do this either by enabling and handling URL segments on a /blog/ page, or you can use a URL/path hook, again in /site/init.php. I'm going to assume there is no /blog/ page, so a URL/path hook may be the best bet: $wire->addHook('/blog/{name}', function($event) { $name = $event->arguments('name'); $blog = wire()->pages->get("/members/blog/$name"); return $blog->id && $blog->viewable() ? $blog : false; }); Are those /members/blog/ pages are access protected from public users? If so, the above hook is not going to let them through because of the $blog->viewable() condition at the end. You could remove that, or better yet, replace it with a different condition: if($blog->isUnpublished()) return false; return $blog->id && $blog->template->name === 'blog-post' ? $blog : false; I can't remember at the moment if ProcessWire does another access control check on the returned page ($blog). So if you find it doesn't work returning the $blog page, try having it return $blog->render() instead.

fyi: here is an issue https://github.com/processwire/processwire-issues/issues/1617

Oh, I see! There is a difference indeed. The site is https://domain.com and the form gets loaded from https://www.domain.com. When I add the www for the site, the form is displayed. So I set htacces rewrite to always use https://domain.com without www. It looks, like it should work. Thank you very much for your help!

You should be able to see more details in the browser's developer console telling you why exactly your browser thinks it mustn't display that part. If the messages in the error console don't give you a clue, you should inspect what happens over the network in your developer console. The most likely explanation for that behavior outside of CSP/CORS headers would be that PW for some reason uses a different domain or http vs. https in the request for the form contents in the embedded iframe.

It's not really going to cause issues, more of a visual misbehavior. Starting with version 3.0.190, repeater labels can contain a hexadecimal color value preceded by a hash sign, e.g. #ff0000. Short notation for CSS colors like #ff1 is also supported, so PW interprets item numbers with more than two digits as colors. My guts say this is unintended and could be easily fixed by reordering the code in InputfieldRepeater so the color substitution happens before replacing the counter placeholder, but the change was inititally targeted at the Repeater Matrix Pro fields which I don't have here. Probably best to file a github issue and let Ryan take a look. These are the lines in question: // update index numbers? if($hasCnt) { // replace "#n" with index number of repeater item $repeaterTitle = str_replace("#n", "#$cnt", $repeaterTitle); } if(strpos($repeaterTitle, '#') !== false) { $repeaterTitle = preg_replace('/#([a-f\d]{3,})/i', "$colorPrefix$1", $repeaterTitle); if(strpos($repeaterTitle, $colorPrefix) !== false) $hasColorPrefix = true; }

I really enjoy your insights and view on this. Especially with the shown example. ? Exactly that. I really enjoyed that video. Even though I really didn't care about his background in first place. The video title was all I needed to watch it.

Thanks! I added my proposed solution to the issue.

I can confirm that behavior here on a pretty clean 3.0.210. Looking at the code, it seems to have been this way for quite some time, so it might even be intended. "Search" shouldn't even be in the menu nowadays, it should be "Find" (and using ProcessPageLister). Did you update that site from an older version?

Nice, thx! Never needed it indeed ? Added to my alias ?

If you don't use phpmyadmin, simply relying on Adminer as part of Tracy Debugger on your sites, you can use the `--omit-containers=dba` flag as well to remove that container from your setup... alias ddpw='ddev config --php-version=8.1 --database=mysql:8.0 --webserver-type=apache-fpm --omit-containers=dba --timezone=UTC' You can also install adminer in it's own container if you prefer to run that beside your PW container... alias ddmore='ddev get ddev/ddev-adminer && ddev restart && ddev describe'

Another reason for using an alias to create your ddev projects: I just realised that the timezone in my project was not correct so $page->modified times where 2hours off. Simple to fix: ddev config --timezone=Europe/Vienna To not forget it for the next project here's my current alias: alias ddc='ddev config --php-version "8.1" --database "mariadb:10.6" --webserver-type "apache-fpm" --timezone=Europe/Vienna'

It's already fixed on the dev branch, I asked for help in the nette forum, thx ?

Log in to your server via SSH and navigate to the site/assets/logs/ directory and look at the end of the errors.txt and exceptions.txt files. You should see information there about what could be happening on the server.

Currently, I barely use Processwire for the frontend, since I am implementing a larger project with vue.js when i have some time, i will have a look at the problem with the tracy panel.

Ok a client wanted me to do some gdpr imrovements so I added this to my Site.module.php ? public function init() { ... $this->wire->addHookAfter('LazyCron::everyDay', $this, 'gdpr'); } public function gdpr() { // delete old rockforms logs $logs = $this->wire->pages->find([ 'template' => RockFormsLogPage::tpl, ['created', '<', time() - RockMigrations::oneMonth], 'include' => 'all', // also trashed pages! ]); foreach ($logs as $log) $log->delete(); // delete old processwire logs $this->wire->log->pruneAll(30); } So RockMigrations just got an update to support time constants: // time constants (seconds) // see https://i.imgur.com/vfTasHa.png const oneMinute = 60; const oneHour = self::oneMinute * 60; const oneDay = self::oneHour * 24; const oneWeek = self::oneDay * 7; const oneMonth = self::oneDay * 30; const oneYear = self::oneDay * 365; And I also found there is $wire->log->pruneAll($days) which is also handy ? Again PW has all the tools to make very custom needs possible with just a few simple lines of code!

Simplest way to test is to edit your root .htaccess in the PW install directory and comment out the X-Frame-Options line (just start the line with a hash character '#') and save the .htaccess file, then clear cache and reload the page in your browser. If it works, then this is the issue and you'll either need to add an exception to the .htaccess to allow frame loading from www.domain.com or re-add the line and fix this a different way to ensure the source and iframe both load from domain.com (or both load from www.domain.com)

I know it's a little counter intuitive, but domain.com !== www.domain.com => not the same origin. Yet it sounds like your server headers are explicitly telling the browser not to load an iframe if it doesn't come from the same origin.

The same origin policy has to match on the domain, port and protocol. So the host page and the iframe source need to be https, on port 443 (by default) on www.domain.com For reference: and only if you actually need to add an exception to the X-Frame-Options header, you'll probably need to edit the root .htaccess file in your pw install to allow it.

So it probably isn't this then, but for reference these are set either in headers returned by the server, or sometimes in HTML in the head section of your page. Headers come either from PHP or from the Apache2 set up - in the .htaccess or apache config files.

I don't know if this was discussed already before... so in case you need to check if PrivacyWire is enabled to show/hide things, like a custom cookie-settings button or link. This is how you check if PrivacyWire is enabled: // needs $config->useFunctionsAPI = true; $privacyWireModule = modules()->get('PrivacyWire'); // check if PrivacyWire is active $privacyWireIsActive = $privacyWireModule->is_Active; // down in your template if($privacyWireIsActive) { // do whatever you need }

It's actually about PHP/Laravel as a backend/middle-man solution instead of all these JS/node.js solutions around and the benefits it brings. The main focus, at least in 2 of the 3 videos, is still somewhat how it works with JS-frontends but still a nice change compared to most other topics in that sphere. You might want to watch or at least skip through some of the videos, the last one is fairly short, to get an impression. It's super interesting, not because of the JS stuff, but because of what Laravel offers and what some see as easy setup and solution compared to what they build as a final product (portfolios, blogs, and such more minimal projects).

Just a follow up to note that my issue with that "WireDataDB sourceID must be greater than 0" error was due to a hook on Pages::saveReady that was setting $page->meta even when the ID of a recently cloned page was still 0. Not something anyone else is likely to come across, but just in case, now you know to be aware of it :)

Hi @xportde and @Grzegorz, I have split your posts from the old long thread and merged them into this new topic. I haven't yet started testing TinyMCE. I have added this to my TODO. Thanks for reporting.

This is true, with a couple of small twists: SearchEngine supports "pinning" specific template(s) to the top of the list, or alternatively grouping results by template. These require making slight modifications (adding extra rules) to the query (DatabaseQuerySelect object) generated by ProcessWire. In the dev branch of the module there is a work in progress "sort by relevance" feature, which also modifies the query. This is based on MySQL natural language full-text search, so it's still up to the database to decide how relevant each result really is. Sorting results by number of matches, giving some fields more "weight" than others, etc. are not currently something that this module does, though I have occasionally considered if they should be. The main issue here is that it would require different storage and search mechanisms, so it's a lot of work, and additionally it would raise a few rather complicated issues (e.g. handling permissions, which is something that we currently get "for free" by relying on selectors.) Not sure how sensible that would be, all things considered. It might make more sense to use SE to feed data to a separate search tool, or ditch SE altogether for that sort of use case ?

90s and early 2000s House/Dance/Techno Remixes #oldschool

Suggesting ProcessWire to your boss. It tend to be similar to answers above, maybe she mean your boss could be your client ?? —- Simple: I can provide you with some key points and resources that you can use to build your own compelling argument in favor of ProcessWire over WordPress. You can use these points to create a presentation, write an article, or as a guide for discussion. 1. Flexibility and Customizability: ProcessWire is known for its flexibility and customizability, making it an ideal choice for projects that require a tailored approach. It allows developers to build custom data structures and tailor the admin interface to suit the specific needs of the project. 2. Simplified Template System: ProcessWire's template system is simple and straightforward, providing developers with the freedom to create custom templates with ease. Unlike WordPress, there is no need for complex themes, which can make site development and maintenance more efficient. 3. Security: ProcessWire has a strong emphasis on security, with built-in protection against common web attacks such as SQL injection and cross-site scripting (XSS). WordPress, on the other hand, can be vulnerable to security issues due to its popularity and the use of third-party plugins. 4. Performance: ProcessWire is known for its fast performance, as it uses an efficient API to access content. This can result in faster page load times, a better user experience, and improved SEO. 5. Developer-friendly: ProcessWire's API is powerful and easy to learn, which can lead to a more efficient development process. It provides a cleaner and more organized code structure, making it easier for developers to maintain and update the website. 6. Supportive Community: ProcessWire has an active and supportive community that can provide help and resources when needed. Although smaller than the WordPress community, it is known for being welcoming and helpful to newcomers. —- Business focused answer: Here are some business and financial-focused arguments for choosing ProcessWire over WordPress: 1. Lower Total Cost of Ownership (TCO): ProcessWire's flexibility and customizability can lead to a lower TCO. Since it is easier to develop and maintain custom solutions, your company may require fewer third-party plugins, themes, and external resources, which can reduce ongoing costs. 2. Faster Development Time: ProcessWire's straightforward template system and powerful API can speed up the development process, allowing your team to deliver projects more quickly. This can result in reduced labor costs and a faster time-to-market, giving your company a competitive edge. 3. Improved Site Performance and User Experience: Better site performance and user experience can lead to higher conversion rates, better user engagement, and improved SEO rankings. ProcessWire's performance advantages can directly contribute to increased revenue and profitability for your business. 4. Reduced Security Risks: Since ProcessWire has a strong emphasis on security, your company can minimize the risks associated with data breaches, cyberattacks, and website downtime. This can save your business from potential financial losses, legal liabilities, and damage to your brand reputation. 5. Scalability: ProcessWire is highly scalable, making it suitable for businesses that plan to grow and evolve over time. Its flexible architecture allows you to easily adapt and expand your website as your needs change, without having to invest in a complete overhaul. 6. Easier Staff Training and Onboarding: ProcessWire's developer-friendly API and clean code structure make it easier for new staff members to learn and become productive quickly. This can lead to reduced training costs and faster integration of new team members, further improving your company's efficiency. 7. Long-term Investment: By choosing ProcessWire, your company is investing in a platform that is built for long-term success. Its flexibility and customizability ensure that your website can evolve with your business needs, reducing the likelihood of needing to switch platforms or undertake costly redevelopment projects in the future. When presenting these points to your boss, make sure to emphasize how ProcessWire's features can translate into financial savings, revenue growth, and a stronger competitive position for your company. Tailor your arguments to your organization's specific needs and goals to make the most compelling case possible. ??

I guess because you are in a module you have output formatting OFF which means that $page->image is an array of images and not a single PageImage object. Using $page->image->first()->size should work. PS: To make everything clear and reduce chances for errors you can be more verbose and use $page->getUnformatted('image')->first()... PPS: Better check if an image was uploaded before using ->size(...) $img = $page->getUnformatted('image'); if($img AND $img->count()) { $img = $img->first(); $img->size(...)->... }