Leaderboard

Thx for the inspiration - this is for you ?

Thx ? Thx for the reminder, I linked the post in the video description! Yesterday I implemented another way of doing the same principle into RockMigrations. RockMigrations has had the initClasses() method, but you had to call that manually and provide the correct namespace. With yesterday's update you simply let the custom page class use the MagicPage trait and RockMigrations will autoload the pageclass on boot and trigger init() and ready() on the correct timing. I didn't want to put that into the video though as it's a very young addition and I've already had to fix some things today. But it looks like a very promising approach to me ? Thx, I'll try my best. It's quite a lot of work, but it's fun.

You're welcome ? Your current implementation of your DL has display: none on the entire definition list (inline styles). I understand this is work in progress, but display: none will be completely ignored by screen readers. I would put the class .sr-only not just on the h2, but on the entire section instead. I just now, on second sight, realized that unter "map options" you have a lot more stuff going on, in an accordion, with all kinds of filters. Previously I just looked at the first accordion item "library floor". As you have correctly mentioned, complex visuals that convey information, need special attention re: a11y. There are no quick shortcuts or golden recipes that help you out. It's all about context. You have put a tremendous amount of work into exploring the building, making sure the user can filter / find everything. This whole "map options" thing is sure a great help for "regular" users who are not visually impaired. Kudos to that. Now, if you look at the big picture, you will realize that all these fine-grained options don't do anything for the non-visual users. They will most likely be confused. If you wanted to build the entire filter/options functionality with a11y in mind, you would need to invest a lot of work. You'd have to use aria-live to inform the user that something has changed in the map after the user made a new selection. Currently, if the user selects the "Glasby Room" radio button, the visually impaired persons don't get the information that regular users get (by toggling/removing the inline display:none). You would have to map these with either an aria-label right at the input level, or with aria-describedby or some such. (I strongly encourage you to test it out yourself with a screen reader - don't rely on automated tests like Lighthouse - they all have their limits, especially when it comes to context) I would personally visually hide all filter stuff under "map options", but provide a table in each accordion item. Tables are well-supported by assistive technologies, while DLs are only so-so. If budget is tight (and it always is tight for accessibility-related work) I'd opt for one big .sr-only table, and use aria-hidden on both the SVG and the filters. Just my 0.02.

I have just released version 2 of RockMigrations: GitHub: https://github.com/baumrock/RockMigrations Modules Directory: https://processwire.com/modules/rock-migrations/ Please star the module on GitHub if you like it ? Are you unsure if RockMigrations is the right tool for you? @Jonathan Lahijani in a very nice PM ? Read the full post here Read the full post here Read the full post here QuickStart The example code uses bd() calls for dumping data. You need TracyDebugger installed! Put this in your site/migrate.php /** @var RockMigrations $rm */ $rm = $modules->get("RockMigrations"); bd('Create field + template via RM'); $rm->createField('demo', 'text', [ 'label' => 'My demo field', 'tags' => 'RMDemo', ]); $rm->createTemplate('demo', [ 'fields' => [ 'title', 'demo', ], 'tags' => 'RMDemo', ]); Reload your site and you will see the new field and template in the backend and you'll see the message in the tracy debug bar.

I'll share my youtube videos in this thread and if you have questions this is the place to ask. You can also subscribe to this thread to get notified when I post new videos ? Here is the link to my channel: baumrock.com/youtube --- Hey! I've just published my very first ProcessWire video. It's about RockFrontend: https://processwire.com/talk/topic/27417-rockfrontend-??-take-your-processwire-frontend-development-to-the-next-level/#comment-225666 Here is the video: What do you think? Do you understand what I'm trying to explain (despite the many ääähms und öööhms...)? ? What about the length?? I really didn't plan do get to 40mins... Did anybody even watch it till the end? ? Would it be easier to follow when having a small thumbnail in the bottom corner when working on the code? Or better without? Is it worth the effort of creating a video or would a readme be just as good? ? Any tips for better sound/lighting? I'm not really knowing what I do, so any ideas for improvements are very welcome ? Better with or without background music? So many questions... So much to learn... ? But it's fun and I'm a bit proud ?

Page Table was developed/intended as a part of the ProFields bundle, but later bundled with the core package, so "ProFields" in the name is kind of a nod towards that history ? There are many ways to handle rendering, but here's one solution that may help you: Create a shared root for your content elements — something like /blocks/ or /content-elements/, perhaps. Configure your Page Table field to save new items below aforementioned root path, and make sure that you only enable templates that you've created for this purpose. You don't want to allow a "regular basic-page" (or anything like that) in your Page Table field as a "content element". For each of your "content element templates", leave template file empty (so that these pages can't be reached with their actual URL). Now even though your content elements will be actual pages in the page tree, they won't be reachable by visitors. You can render them in any way you see fit, but here's one approach using ProcessWire's native field rendering feature that, in my opinion, works pretty well. Here I've assumed that the Page Table field is called "blocks", and it's used on template called "basic-page". /site/templates/basic-page.php <?php namespace ProcessWire; ?> <?= $page->render('blocks') ?> /site/templates/fields/blocks.php <?php namespace ProcessWire; ?> <?php foreach ($value as $item): ?> <div class="block"> <?= $item->render(__DIR__ . '/blocks/' . $item->template . '.php') ?> </div> <?php endforeach; ?> /site/templates/fields/blocks/block_template_name.php <?php namespace ProcessWire; ?> <h2> <?= $page->title ?> </h2> <?= $page->content ?> Anyway, as I mentioned that's just one approach ? I'm not entirely sure what you're referring to here, but if you mean the processwire.com website, then yes — that's technically proprietary. In my experience that's a common thing for open source projects. API reference, on the other hand, is automatically generated from ProcessWire's source code, so that is technically open source ?

Thanks - I wasn't thinking about that Login option - yes, I think it is handy - much nicer that the core login dance :) Yeah, I suppose we could go with 41 or the first available superuser, but if I implement this, I think it would be better to use the user switcher and have the option to choose. Regarding having access to everything on the bar already - that's not quite true - I do also prevent access to Adminer in this situation. Whether I really have good justification for that or not is another question, but I do want to have a more thorough think through this moving forward to make sure I am not overlooking anything of concern.

@kaz on my install "ProFields: Page Table" is listed in the core things I can install. I did not have to download anything extra. Perhaps you have an older version of PW? I am experimenting with that module but needing to step back to understand the rendering process; at the mo I get whole 'pages' output, with header navs etc. for each item in my Page Table field! I'm still evaluating, but I'm not sure I like/want the individual 'paragraphs' (Drupal speak) or 'blocks' (Gutenberg speak) to be separate pages with separate publication statuses, URLs etc., but I may get to something usable in the end. It's new for me to deal with the concept of non open source documentation for a (now) open source project; seems quite strange. Anyway, I'm still experimenting, I thought I should try to understand that module first before the PageTableNext one etc. Open source is a must for me, so I'm not going to evaluate Repeater Matrix.

yes, your update fixes the issue, thanks!

@bernhard, what can I say? A new star in born! ? Excellent video! For future reference I link here a post where you already explained the use of custom classes (with a slightly different approach for exposing the init() method inside the class). Btw, I already subscribed to your YouTube channel! Keep going!

Personal opinion: I think if I were to make a decision on what I see about Payload, I'd probably (personally) opt for Statamic for two reasons: I'm more familiar with PHP, and since it's a file based CMS and can be run directly from a Git repository, it makes things simpler (even if the installation is, IMHO, ridiculously bloated: thanks Laravel). I see some level of inspiration in it by Statamic, Kirby, and maybe Wagtail, but obviously with its own take on it all. For Directus: I don't personally see that as a CMS - or at least CMS-first option. If I remember correctly (I might not), it was originally advertised as a visual data query builder, enabling the ability to connect to an absurdly large amount of disparate datastore solutions, and then (visually) build queries to concoct interfaces and/or reports related to that data. Can you build a CMS with it? Apparently so! Should you build a CMS with it? I suppose that depends on exactly what it offers. I haven't personally tried it, even though I've kept my eye on it in case I had a project that seemed to fit. So far I (unfortunately) haven't. (I kind of want to play with it. It looks ridiculously powerful.) All that said, I haven't tried either, so my involvement isn't exactly what you were hoping for. As far as RestAPI and GraphQL, are the related modules insufficient? (I know you said default modules, so my curiosity is only adjacently related.) I definitely enjoy comparing and re-evaluating tools though, so appreciate this hashed, and rehashed, and rehashed topic! ?

I've edited my statement from 2019. Ryan has already pulled in several contributions and said he is happy to add others. So I think while it does not happen very often (which has the benefits that @pwired mentioned) it is not true (any more?) that PRs are ignored ?

Edit: Sorry for double-posting, I forgot that I already posted that yesterday! I've fixed a bug though and the color now comes from the AdminStyleRock setting which makes it even more great ? --- When using the latest version of AdminStyleRock you'll get perfectly aligned frontend + backend styling using ALFRED frontend editing: Backend Inline Editor Modal Editor You'll get all that by changing only a single color in AdminStyleRock:

Yes, I understand that. They have the free choice to do it the hard way if they feel more secure then and come up with all the same questions that I came up with while developing the module. Nice idea but simply not possible. There has been a lot of discussion about that. See https://processwire.com/talk/topic/26565-share-your-pw-dev-setups-tools/#comment-220383 What you describe is exactly where RockMigrations shines. I keep repeating myself. And people keep not using RockMigrations. That's ok, but I'll not go into details of your question again. I've explained often why something that you describe is not a good solution. It might be a little easier to use, but it does not make the solution better in the big picture.

Since these tags are introduced by CKEditor you know they’ll always be there and always look the same (I guess). So you can pretty much just count how many characters you want to skip at the beginning (3) and end (4) and do it without ever mentioning anything about <p> and </p> to PHP: $bodyCopy = mb_substr($pages->get("/nastavitve/")->kontaktni_podatki, 3, -4); Or you can go the replace route: $bodyCopy = mb_ereg_replace('^<p>|</p>$', '', $pages->get("/nastavitve/")->kontaktni_podatki); Note how using mb_ereg_replace you don’t need those annoying slashes. The regex ^<p>|</p>$ just means, “find a <p> at the beginning OR a </p> at the end”, so this leaves all the inner p-tags alone. You can get more fancy if you need to take into account all the ways a HTML tag might appear, but eventually you’ll get into this territory. There is also the ol’ strip_tags function and ProcessWire ships with a Textformatter module called ParagraphStripper, I believe. As well as HTMLPurifier if you really want to get your hands dirty.

Table Use this for tabular data, like rate tables or other things that you might typically represent in a spreadsheet. Use it for situations where you don't need the full-blown flexibility of repeaters, as it's technically more efficient with far less overhead than repeaters. Something like the Events Fieldtype could be very easily re-created via a Table field, but the potential uses are far broader. But for the most part, think tabular data when it comes to the Table field. Multipliers This is good for when you need a range of values (whether text, textarea, numbers, dates, etc.). If you are using repeaters with just one field in them, you might be a lot better off with a Multiplier. Like the Table field, Multipliers are very efficient and low overhead relative to something like Repeaters. Use Multipliers when you need to repeat a single input multiple times, optionally with a min and max number of inputs. Lets say you are building an employee directory, and each employee has between 1 and 3 email addresses. Rather than using 3 separate email fields, you would use 1 multiplier field and specify min=1 and max=3. Repeaters These are infinitely flexible in terms of what they represent, but each row of values is technically a page in the system. As a result, with the flexibility comes significant overhead. This is really only an issue when the quantity of repeater items gets high, or when you have lots (thousands) of pages using repeaters. I recommend repeaters for setting up things like homepage carousels. For example, if you go to the Villas of Distinction homepage, there are 3 separate repeaters in use on that page, each holding a photo, title, description, link. The client can have as many items in each of those sections as they want. Currently it looks like the first repeater as 6 items, the 2nd has 2, and the 3rd has 6. The possibilities of what can be represented with repeaters is endless, but look for potential alternatives when dealing with large quantities (whether large quantities of repeater items, or large quantities of pages using repeaters). PageTable This is one of the ProFields that is available for free (thanks to Avoine sponsorship) on the ProcessWire dev branch. Meaning, it'll be available for everyone to use as part of the core in ProcessWire 2.5. And you can use it now if you don't mind running the dev branch. PageTable has all the flexibility of repeaters, but with lower overhead from the admin/input perspective. Rather than trying to bundle all the inputs on one screen, PageTable shows you a table of items and you click on the item to edit it in a modal window. This enables it to be a lot more efficient from the admin UI perspective. It's also more flexible than repeaters are in terms of where you store your items. PageTable lets you choose where they should live, whether as children of the page being edited, or as children of some other parent page you designate. They might be a little more work to setup than repeaters, but I think that most situations where you need the flexibility of repeaters may be better served by PageTable. PageTable still can't compete with the speed and efficiency of Table or Multiplier, but consider using PageTable anywhere that you might have used Repeaters before. Repeaters and PageTable are fundamentally different from the admin UI/input perspective, so you'd want to compare them yourself to see what suits your individual input needs better. PageTable involves more clicking to create and edit items, making Repeaters potentially faster for entering data rapidly. But PageTable will scale much further in the admin UI than Repeaters will, so I would personally favor PageTable in more situations than Repeaters.