• Content count

  • Joined

  • Last visited

  • Days Won


BitPoet last won the day on June 13

BitPoet had the most liked content!

Community Reputation

1,811 Excellent

1 Follower

About BitPoet

  • Rank
    Hero Member

Profile Information

  • Gender
  • Location
    Near Munich / Germany
  • Interests
    programming, writing, scuba diving, long distance hiking

Recent Profile Visitors

4,939 profile views
  1. The message complains about $u being empty (i.e. a NullPage object), so the call to $users->add didn't succeed. A likely cause is that a user with the name you are trying to add already exists. You should check the return of $users->add, or even better, check if the name in question is already there beforehand and output a message accordingly (and don't forget to sanitize the form input). There's also a nice API to access GET and POST parameters in ProcessWire. Instead of using e.g. $_POST["submit"], you can access $input->post->submit and don't trigger warnings/errors when that parameter isn't defined.
  2. BitPoet

    Is mod_security enabled in the web server? If yes, it would be the first suspect.
  3. The textformatters attribute is defined/set in FieldtypeText::___getConfigInputfields and its value is used in FieldtypeText::___formatValue.
  4. BitPoet

    Is your harddrive full? It might be that the files in question don't fit on the drive where PW resides while the images get downsized and can manage to squeeze into the leftover space.
  5. BitPoet

    That "api_key" part looks fishy to me. A copy&paste artefact?
  6. In most cases you can solve that through field permissions. Add a custom role if you need some non-superusers to change those layout images, then check "Manage Access" for the field, add your new role and remove the regular editor role. Only editable fields will be selectable as upload targets. You should be able to preselect one image field with a piece of custom javascript (you can use AdminCustomFiles to inject your script into the correct process), but I don't have an example for that. If you need to make things more dynamic, you probably have to do some text search and replace in the output of ProcessPageEditImagSelect::execute since the method that gets the list of target fields for the "Upload Image" button isn't hookable.
  7. Actually, you wouldn't even have to pass the filename. If you assemble the image URL like this, you could just as well use a unique parameter that tells your hook to output the image contained in whatever field you want and can stop worrying about exposing the wrong file. Like {$page->url}?showprofileimage=1.
  8. That's likely not going to be trivial. Adding check_access=0 in a selector to display the link is quite another thing as serving the secure file to a guest user. When you have pageFileSecure enabled, the following happens: PW prefixes the file directory site/assets/files/[PAGEID] with $config->pagefileSecurePathPrefix ("-" by default so it will be site/assets/files/-[PAGEID]) When the browsers tries to show the image (i.e. open the URL /path/to/pw/site/assets/files/1258/image.jpg in a separate request), the file isn't found by .htaccess .htaccess hands off the request to index.php index.php calls PageRender::execute with the request URL PageRender::execute checks if the request is to a file, then checks if the page it belongs to is published and viewable by the current user Since $user->hasPermission('page-view', $page) returns false (the guest user doesn't have view permissions) that fails (otherwise, PW would prefix the path now and output the file) PW outputs the 404 page Since the method where the check is are done is not hookable (and some necessary properties and methods are protected, i.e. not reachable from a hook) you'd probably have to hook before ProcessPageView::execute and duplicate a lot of code from ProcessPageView or hook after User::hasPagePermission and at least duplicate ProcessPageView::checkRequestFile in both cases, match the file URL to $page->image to prevent handing out a access to other file/image fields on the page Another approach (if the images aren't too big and the protected pages aren't too many) would be to include the real image data as data URIs: <?php foreach($protected_pages as $protected_page) { echo $protected_page->title . "<br>"; $fn = $protected_page->image->filename; $imgdata = "data:" . mime_content_type($fn) . ";base64," . base64_encode(file_get_contents($fn)); echo "<img src='$imgdata' alt='{$protected_page->image->description}' />"; } If the images are small enough but you have many pages, using PW's pagination might be an option too.
  9. IMHO building your prototype with PW gives you a solid base from which you can go in every direction. You can build just a part in Vue and let the Vue app grow over time. There's a little bit of effort involved to tie PW's pages, fields and templates and Vue templates together smoothly without a lot of overhead, but an experienced Vue dev should be able to wire that up quickly and in a reusable way (Vue would be my choice there as well). Exposing PW pages and limited write actions through ajax isn't hard to do either. It's also a walk in the park to migrate PW content into less normalized "external" tables with a small bootstrap script if performance really requires it, so unlike other CMSes where you have all kinds of different things (posts, pages, parts, whatever) in different structures, you don't really lock yourself in with PW. I agree with @LostKobrakai insofar as that there are in fact a few areas where a custom tool will get you further, like if you need a full-blown discussion forum. The choices there are rather limited if you want a good integration. Invision (the software this forum runs on) seems to be rather straight forward in that regard. I have tried my hand on a phpBB3 integration module and while the basics mostly work, it's really a PITA in some parts (like outdated examples and misleading documentation) and I've run out of time to get it into a really usable shape. There are probably a few Laravel forum components I've never heard of that can get you most of the way as a half way option. I think that will be the hardest part to decide, where will PW (or any other CMS or own development, in fact) ever only be the second best choice compared to a single purpose tool you can integrate.
  10. BitPoet

    Here's a try: <?php echo (selectorsMatch("baths>1, template=listing", "template=listing, baths>1")) ? "Match" : "No match"; function selectorsMatch($sel1, $sel2) { $s1 = new Selectors($sel1); $s1->sort('field'); $s2 = new Selectors($sel2); $s2->sort('field'); return "$s1" == "$s2"; } Not sure how this behaves with OR-groups, but it should be fine for simple AND selectors.
  11. In my personal opinion the definition is rather fluid and depends on too many factors to give a generic rule, but I consider a site highly dynamic when multiple components of often visited templates (especially home and other landing pages) have user or group specific content and that content changes more often than on a daily basis. Whenever I see "social" or "communities" in a site's description, that's likely the case.
  12. Find queries are cached for the lifetime of a request. Caching them more permanently needs additional code. I think there was an example for using MarkupCache to store JSONified query results in the forum a while ago, but I might remember wrongly. With highly dynamic sites, everything you know about caching best practices is at first no longer valid. Until you start factoring out the dynamic parts, that is. Decouple searches from the database by using a dedicated in-memory search engine (Lucene, OpenSearchServer etc.) to avoid high loads and table level locks. Cache IDs and values retrieved from frequent searches in memory (like newest n posts/comments), and when you scale up, delegate the job of updating those to cronjobs to eliminate any delays caused by rebuilding expired memory caches. Retrieve dynamic parts of the page through JS in JSON format and render them with a frontend framework so the static parts and templates can be served from the filesystem (that's where ProCache ties in). Design your pages to use placeholders for dynamic content so your users don't have to wait for client side rendering of dynamic content before they can start using the page.
  13. If you use mod_security with a CMS it isn't specifically aimed at, this is exactly the kind of nonsensical errors you will get since its pattern matches will only make sense in the context of that CMS (mostly WP). Even with a supported CMS you will likely encounter that kind of error if you build a complex, dynamic site or use less popular plugins, and you will have to adapt the rule sets. I'm pretty sure you'll find log entries from mod_security that match your 403s and 404s.
  14. BitPoet

    @Xonox, have you seen Inputfield Page Autocomplete?
  15. BitPoet

    PHP probably runs under the user configured in your anonymous authentication settings. In IIS manager, click on your website, then on "Authentication". Select "Anonymous Authentication" and click "Edit" in actions bar at the right. There you will see the user (default: IUSR). Grant this user modify permissions on the assets folder.