Jump to content

MoritzLost

Members
  • Content Count

    211
  • Joined

  • Last visited

  • Days Won

    11

MoritzLost last won the day on August 5

MoritzLost had the most liked content!

Community Reputation

603 Excellent

About MoritzLost

  • Rank
    Sr. Member

Contact Methods

  • Website URL
    https://herebedragons.world/

Profile Information

  • Gender
    Male
  • Location
    Cologne, Germany

Recent Profile Visitors

956 profile views
  1. Alright, I see. Though this makes sense, even if you include a different PHP template, you're still viewing a template of type "home", and ProcessWire uses the settings of this template to determine stuff like pagination, url segments, caching etc. For the record, this is what I meant by Have you made sure that the pagination option is active in both templates you need it in? 😉
  2. @Pip Glad you found the cause of the issue, but could you clarify what you mean by your home is not allowed to do pagination? Is the option not active in the template?
  3. Not sure if this is documented anywhere, but you can use the RepeaterMatrixPage::matrix() to get the label: // get the label in the current language $page->my_repeater_matrix_field->first()->matrix('label'); In recent versions of RepeaterMatrix, you can also call RepeaterMatrixPage::getMatrixInfo() to get an array of information, including the label: $page->my_repeater_matrix_field->first()->getMatrixInfo();
  4. @Pip Hm, the code looks good to me. Have you made sure that the pagination option is active in both templates you need it in? Other than that ... maybe calling renderPager() twice is tripping something up? Maybe save the result in a variable and output that instead. Also, you sort by ID? That's curious, are you relying on newer pages having higher IDs? In this case, maybe just sort by created date (sort=-created). And again, have you made sure there's no caching active on any layers?
  5. Not sure, but I don't think so. It's primary function is to list and edit existing pages. Might be there's an action for bulk import / creation, but I haven't seen it yet. But again, if your client absolutely needs something like that, why not build a simple interface that will allows them to batch create pages? See the example code above by @Kiwi Chris, it's literally that simple. I've even done some imports directly from the Tracy Debugger Console before, and it took like 15 minutes ... all you need is a couple of lines to create a new page, and then assign values using the field names in your template. Add an file_get_contents to read from a CSV file or something, a foreach loop and you've got your reliable and simple pages import.
  6. I just published version 4.0.0 of this module, a large update that makes it possible to completely customize the markup created for detected page titles. For example, let's say you have a glossary and want glossary terms that appear anywhere on your site to display a popover with the term's definition. This update allows you to do that! Previously, the module always created an <a> tag with an href attribute, and always checked if the page was viewable before doing anything. This update comes with configuration options to change the HTML tag, disable the automatic href attribute and disable the visibility check. This allows you to use the module for a wider range of use-cases. If you need even more control, the methods the module uses to create markup are now hookable, so you can customize the output format even further! Here are some additional links to help you get started: There's a new step-by-step guide for a setup with glossary terms with inline definitions. Both new hooks are documented with usage examples in the hooks documentation, learn how to customize the markup generated for titles and how to add attributes to the generated link / HTML tag dynamically. All the new options are available for manual usage, find the list of options here. Check out the CHANGELOG for version 4.0.0
  7. You need to remove the start=0 from your selector. Automatic pagination works by automatically injecting the start parameter into all pages queries with a limit, based on the defined limit and the current page number. By including a start selector you overwrite this behaviour, forcing ProcessWire to not return paginated results for that query. See Pagination in ProcessWire, section "Are there any side effects?" If it isn't working without the start selector either, and it's just not working sometimes, it might just be a caching issue.
  8. @fruid I don't really understand your use-case. You say your client is going to use SQL to update the database, does that mean they are going to write raw SQL queries in front of a terminal? That seems like a really inefficient way to go about content creation, especially since you have to make sure your data fits within the constraints defined in the template and field settings. Despite that, you can still do that, you just have to add a couple of JOINs and be careful with your WHERE clauses. Each field table comes with a foreign key corresponding to the page ID. If your client is really some kind of SQL wizard who prefers the power of raw SQL for data migration over the limited interfaces puny mortals have to use, what's stopping them? Or do you mean "the client is going to log into phpMyAdmin / Adminer / MySQL Workbench / ... and insert data through that interface"? In that case, you're not really using SQL anyway, you're just using an interface that's closer to the database, that *may* be slightly more efficient to use for batch creation / updates if you really know what you're doing. If that's what your client wants – well, that's an interface you can build for them! Something like a batch update module that lists pages and allows you to edit them inline. In fact, such a module exists already: Lister Pro comes with inline editing for multiple fields at once. This gives you a convenient interface to update many pages at once and still stay within one backend and have all the input / constraint validation apply to your edits. Best of both worlds 🙂 By the way, if you've ever tried to manually find something in a Drupal 8 database, you will like ProcessWire's database structure MUCH more ...
  9. It happens to all of us 😄 This is actually why I dislike the use of the magic methods like __call, because they make tiny mistakes like this harder to spot ... without the magic, this would just result in a clear, easy to fix error message, but with it it's way harder to figure out what's going on.
  10. Not quite sure what's causing the recursion error, but your method is marked private, which means it can't be called from outsite. Because your page class extends Page which extends Wire which comes with a magic __call method that will be invoked in this case. That method tries to figure out what you're trying to do, since it's supposed to provide easy access to properties and methods of all Wire extending objects. The error call stack indicates there's something going wrong there. Making your getSummary method public should fix the issue!
  11. @ryan Thanks for the reply! Sorry, I failed to mention that I'm talking about pasting text through they context menu (right-click -> paste). In this case, they keyup event is not triggered, because no key was pressed. Pasting with CTRL / CMD + V works fine. Great, thanks 🙂 We use Twig for most of our ProcessWire sites, which comes with autoescaping. In this case, having the formatter on leads to double escaping, and it's easier and more consistent to have Twig handle escaping everything by default.
  12. No, that's a common misconception. There's no security benefit at all (it can be bypassed super easily), but comes with multiple downsides (worse UX, higher chance of typos). It may even decrease security because it discourages the usage of password managers. See security.SE, NCSE and web.dev for reference. By the way that's only slightly related to this issue. The profile page does allow passwords to be pasted; but the inputs for the new password are only activated after the old password field has been typed into, and that event handler only listens for input events, not paste events.
  13. Where exactly are you stuck? Differentiating between normal and AJAX requests, rendering content (are you doing that server- or client-side?), encoding the content for the AJAX response? An example of your current code and what's not working about it would be helpful. A couple of observations, in no particular order: The first thing I notice is that the infinite scroll library you linked seems to employ a non-standard way of doing "load more" buttons. Instead of requesting only the new items, it works with an existing classic pagination and just loads the entire next page, throws away everything but the new items and adds them to the existing container. While this does work, it's incredibly wasteful, loading entire pages just to discard most of them immediately. So don't let that library trip you up if you want to build "real" AJAX-powered pagination. What endpoint are you calling in your AJAX request? I remember some tutorials around here recommending to hit the same URL as a regular page view, and differentiating between normal page views and AJAX calls by checking the X-Requested-With header – in my opinion, that's not a good approach. It doesn't even work properly if you use the Fetch API (the modern alternative to XMLHttpRequest). Depending on how much side-loaded content you need on your site, I would either use a URL parameter (?ajax=1) or build an entirely separate endpoint (/api/events/...). The latter approach scales much better. Are you returning HTML or structured data from your endpoint? Depending on that: Returning structured data, i.e. a JSON-encoded object with information about the events is the cleaner way to go about this. But since the first five elements are already rendered server-side, that means you have to replicate your template-logic in JavaScript to create the same HTML structure that the server-rendered events have. Not ideal. In general, I only use this approach if the entire app is client-side rendered (like the Architekturführer Köln). Returning server-rendered HTML is not great, because it makes your API non-reusable (for example, if you want to display side-loaded events in different places with slightly different layouts, you'll need separate endpoints or parameters). It's also just not very clean to insert raw HTML into your page. Though it is a bit easier for simple use cases. I need to mention this: Do you really need to side-load your events? It's one of those features that clients go crazy about because it's "cool and modern", but why not use a regular pagination, which works out of the box and is also better for SEO? If the reason is that your visitors need to load too many pages this way, is there any reason why you can't just show 25 events per page instead of 5?
  14. Absolutely you can! You just need to get the page the repeater items are on, then you can access the repeater items on it. Based on your code above it should be simple: $id = 1234; // replace with desired page ID $alertspage = $pages->get(id); // replace "alerts" with your repeater field name foreach ($alertspage->alerts as $alert) { // do something with the repeater items ... }
  15. Yes, this is called bootstrapping, see the documentation. Basically, you only need to include ProcessWire's index.php, then you can use the API as usual. The only difference is that you won't have access to the $page variable, since it's not a regular ProcessWire page request, so ProcessWire can't associate a particular page with it.
×
×
  • Create New...