Jump to content

kongondo

PW-Moderators
  • Posts

    6,771
  • Joined

  • Last visited

  • Days Won

    116

Everything posted by kongondo

  1. Hi @ctech, Sorry for the very late response. Maybe something like below to get you started? I have deliberately left in debug code so you see what's going on. I am also using findRaw() for efficiency. You can go a bit crazy with limit if using findRaw() 😁. <?php namespace ProcessWire; // we only need this one field $fields = ['blog_date']; // get some posts, sorted by date, ascending $posts = $pages->findRaw("template=blog-post, sort=-blog_date, limit=25", $fields); bd($posts, '$posts at line #' . __LINE__); $posts2 = []; // if we got results, format and use them if (!empty($posts)) { // make it clean (not strictly necessary) $posts2 = array_column($posts, 'blog_date'); bd($posts2, '$posts2 at line #' . __LINE__); $monthArchives = []; foreach ($posts2 as $dateString) { // get the month portion of 'blog_date' $month = $datetime->date('F', $dateString); // get year portion of 'blog_date' $year = $datetime->date('Y', $dateString); bd($month, '$month at line #' . __LINE__); bd($year, '$year at line #' . __LINE__); $monthArchives[$month][$year] = $year; // @TODO: DON'T KNOW WHAT YOU WANT THE VALUE TO BE HERE } bd($monthArchives, '$monthArchives at line #' . __LINE__); } // do something with $posts2 if (!empty($posts2)) { // code } Hope this helps πŸ˜€.
  2. Hi @Orodreth, I merged your thread here thinking that this had to do with the Blog module. Now that I look at it closely, it looks like it is a problem with SchedulePages. I have never seen this error before but I have also not touched the module in a long time. Maybe something changed in ProcessWire since. Are you able to do do some tests so we can try to get to the bottom of this? E.g.: Install SchedulePages without the blog module. Do you get errors? Install SchedulePages in an earlier version of ProcessWire, maybe 3.0.16x. Do you find issues? I am afraid I am currently short of time so cannot investigate further until the net we cast is a little bit narrower, hence above suggested investigations. Thanks.
  3. That is the default behaviour. Alternatively, you can use the method $modules->getModule() with noInstall option. <?php namespace ProcessWire; $modules->getModule('MyModule', ['noInstall' => true]);
  4. Hi Ross. ProcessWire has zero-influence on how your frontend looks like or what strategy you adopt to present your frontend. This is 100% up to you. It is the result of the code you have in your template files. So, what you inherited was the previous developer's strategy for outputting frontend content. In short, ProcessWire does not get in your way. In contrast, it does offer you the tools (via its API) to do various things including fetching data from the backend to show on the frontend. In this respect, it does not matter if your ProcessWire version is 2.3.1. However, there have been numerous improvements to ProcessWire since 2.3.1, too numerous to list here, that make it compelling to upgrade to version 3.x. How to upgrade from a version that far back is a topic on its own but there are threads in the forums (and maybe something in the docs but I am not 100% sure) to help you out. Let me quickly point out that It is not required to upgrade. ProcessWire 2.3.1 is perfectly safe to use. As for responsiveness, that is up to you and your CSS. How are your skills in this area?
  5. Brilliant! Glad you got it sorted 😁.
  6. Usually we sanitize at the earliest opportunity available. It is also good practice in case you forget or move things around. So, this is better and less verbose: <?php $url_exhibition = $sanitizer->name($input->get->text('exhibition')); ?> As for which sanitizer method to use, the docs are helpful, but you are probably aware of it already. Just nitpicking now... You could probably check if $url_exhibition is NOT empty before continuing with the subsequent code, i.e. the pages->get and the rest of the code πŸ™‚.
  7. Glad you got it sorted. I have just noticed that you are using a GET input in a selector without sanitizing it first. Here: $url_exhibition is not sanitized and you immediately use it here:
  8. I struggle to read alternative PHP syntax but it seems to me you haven't defined $currentKey before the condition at line #55. If exhibition work title is not equal to the page title, you have no $currentKey, hence incrementing it at line 59 throws the error. Defining/initing it earlier, before line #55 ought to get rid of the error. E.g. $currentKey = 0; Not sure that your code will still work as intended though, so you'll need to test.
  9. They are in the docs right here for text(): https://processwire.com/api/ref/sanitizer/text/ but you are right, it is not clear from the docs if these also apply to textarea().
  10. Free access to Flutter Apprentice from October 6, 2021 through January 6, 2022. https://flutter.dev/apprentice-giveaway
  11. I have learnt (sometimes the hard way) that mixing values or data types in the database for the sake of UI/UX is never a good a idea. Modelling a real world problem is many times not straightforward. Reading up on DB normalisation helped clarify things for me. Before I design any DB model / schema I ask myself two basic questions: Will users need to query the data? (e.g. searches, selector) Will the data require manipulations at the DB level? If the answer to any of these questions is YES, I throw out any notions of storing data as JSON. In 90+% of the time this will be the case. The data will need to be queryable. In fact, I rarely store anything as JSON (even with the not-so-recent MySQL JSON-capabilities - the pros and cons of which are a debate for another day, btw). The only thing I store as JSON are things like site settings, data points of a map for a chart, etc., as these don't need querying or direct computation applied on them. In this Fieldtype's case, I would steer away from JSON. The name of the field itself implies mathematical computation will be involved. I would use a DECIMAL data type to store the quantifiable values. You will then be faced with the age-old question of whether to expand horizontally (add more columns to accommodate more combinations of feet|inches- i.e. regular relational design) or expand vertically (add more rows - i.e., Entity Attribute Value [EAV]). Each of these have their pros and cons. Probably one way to do this is to try and ensure that you are comparing apples to apples at the DB-level. You can decide on a base unit that will be used to store all measurement values. For instance, centimetres. In the UI, the users will always see their measurements in the selected unit (feet, inches, etc). You can already see the problem with this 😁. It requires knowledge of the type of measurement that is being stored, e.g. length, volume, area, etc! Does it mean you will have a base unit for all these groups of measurements? What about custom measurements that don't readily fit into one of these paradigms? I am probably overthinking this. Or I have been working on Padloper for too long 😁. Good decision. I think it is 'easier' to bend the UI/UX to fit your DB model than the other way around. Sorry, I don't have much answers at the moment but hopefully this helps generate a meaningful discussion.
  12. Thanks for this contribution @MarkE, Is there a reason you combine magnitudes into pipe-separated values? This makes it difficult to query. For example, what if I wanted to find values whose magnitude were > 10? Storing these pipe-separated strings make this tricky. I have only quickly looked at the code so you could have already figured this out. Combination units: I think I get the idea for this (e.g. the feet and inches). From an UX/UI point of view though, maybe it is prone to errors? Editors need to remember to input a pipe as well as remember what side of the pipe is what measurement. Maybe this is an exaggeration, as it is quite easy to remember feet|inches but what if it is another not-so-obvious combination? The auto-conversation feature looks cool though πŸ˜€.
  13. Hi Simon, Apologies for the late response. I haven't touched this since I built the prototype. I think the Page Builder conversation isn't finished yet. Some of the pending discussion IMO are: What type of Page Builder do people want? E.g. drag and drop with visuals, repeater-like-builder, etc. Technical aspects of the builder: e.g. coupling with existing ProcessWire fields or not, or both, etc. Community (seems more people prefer this(?)) -led versus commercial (other?) project/module. If community-led, who are the leads? Page Builder built on top of repeaters (seems many people would prefer this (?)) or separate module? Strictly Page Builder or a site builder as well? (maybe not as important a conversation to have). Are you building something yourself? Thoughts? Thanks.
  14. That is probably not a valid ProcessWire page. ProcessWire does not output page URLs with .php extensions. A frontend page would be something like www.mysite.com/about-us/ or www.mysite.com/services/. In case you don't know which pages use which templates, find out if you have a template file called home.php and use that instead of basic-page.php. In that case, you would then have to visit www.mysite.com for the code to run. Yes, it's always good to make a backup of the database. In this case a backup of the files is not strictly necessary but it does no harm if you do. Let us know how it goes πŸ™‚.
  15. I am wondering if this is happening only on multilingual sites (although I fail to see the connection why)? Is your site Multilingual? @AndZyk. Is your site multilingual? Mine is.
  16. EDITED It should work for 'usual frontend' pages. Since non-super users will have view permission for such pages. The added layer of restriction with respect to repeaters wouldn't apply. Hope this makes sense. For instance, if you had a 'members' field that is only viewable to 'members', logged in members (non-superusers) will be able to see the field as long as that field was on a page that members have page view or edit access to. Meaning, if that page is not a child of an admin page (e.g. repeaters, etc), the permission set will kick in.
  17. Maybe because of this? Repeaters are admin pages. Guests do not have view access to repeater pages (page where the field exists), hence, even though guest had view permission, they still couldn't view the field since it lives in a restricted area (repeater). In other words, their view permission was not 'applicable'.
  18. Where is Schule and Meht Erfahren coming from? Is Schule coming from $page->title? Where is the content Musik erlerenen coming from? From $page->body? Or some other field? I am asking since there could be one or more permission restrictions in place. Possible issues: You have in condition in your template file that is restricting the output of the content. It could even be a hardcoded value of a page ID that doesn't existing in your import site. I.e., in the export site, SOME_PAGE might have the ID 1234 which when you import in your local/other site is saved as SOME_PAGE with ID 1255. You have a field-level view restriction. Especially if only the content of one field is not showing, I would focus on this. You have template-level view restriction. This means that SOME_PAGE utilises 'some-template' which has view restrictions. Is this happening on all the pages? Is it happening on pages that use different templates?
  19. Hi @Allan, Welcome to ProcessWire and the forums. moderator note: I merged your two posts. I also added code blocks around your HTML code for better readability. In addition, I wrapped it inside a spoiler because it is a long piece of code. This also helps with readability (and scrolling).
  20. Depending on what you are doing with the pages, you could do a $pages->findRaw($selector,$fields); instead.
  21. 99.9% of the time I use option #1 as detailed here, i.e. multiple sites with multiple databases AND ONE wire folder. Each site has its own database and /site/ directory (templates, modules, etc.). If I need a site (project) to be stand alone, I create the site separately with its own wire folder.
  22. Thunder Client β€” lightweight alternative to Postman Thunder Client is a lightweight Rest API Client Extension for Visual Studio Code (it is not open-source). Launch article Quick demo
Γ—
Γ—
  • Create New...