BitPoet

Members
  • Content count

    580
  • Joined

  • Last visited

  • Days Won

    19

BitPoet last won the day on December 31 2016

BitPoet had the most liked content!

Community Reputation

1,281 Excellent

1 Follower

About BitPoet

  • Rank
    Hero Member

Profile Information

  • Gender
    Male
  • Location
    Near Munich / Germany
  • Interests
    programming, writing, scuba diving

Recent Profile Visitors

4,069 profile views
  1. Ryan made AdminThemeUikit::renderBreadcrumbs hookable in the last update, so it's time to try out different ideas.
  2. Have you tried to use an absolute path like this? <?php $manifest_path = $config->paths->templates . 'path/to/manifest.json'; // ...
  3. This can be done by installing the page-publish permission. Go to Access -> Permissions -> Add New in the backend and select the page-publish permission there. Afterwards, page-create and page-edit alone will only allow the creation and editing of unpublished pages.
  4. Add them to $config in site/config.php and you can access them like every other configuration option. Just make sure to use a naming scheme that's unlikely to clash with future standard options. I tend to prefix mine with "cust".
  5. Yes, that too. In combination the code could be as straight forward as this (example for site/ready.php): wire()->addHookAfter("Page::loaded", null, "conjureField"); function conjureField(HookEvent $event) { $page = $event->object; if($page->template->name != "event") return; $settings = $pages->get('/admin/settings/'); $page->set("magicalfield", $settings->wholedaytext); } Then "{magicalfield}" works in the event template's page list settings, you don't have to store anything (so if you want to change the text, there's no need to update existing pages), and you don't have to loop over languages since the built-in multi language support works its usual magic.
  6. How about a generic settings template + page where you can enter the translations in a regular text field? Then just get that settings page and use getLanguageValue() for that field.
  7. Ah, that reads a lot more doable then For a dozen tables, I'd probably create the templates and their fields by hand as it is a one-time thing. Perhaps you can name the templates like the old tables for easier coding later. Then create a page field on the main template for every linked table and limit it to the according support table template. Your import routine can focus on creating pages with the correct template and filling in the data. The old id can just go into a dedicated field in the support template, and once all your support table pages have been created, you can use simple selectors like $pages->get("template=oldtablename, keyfield=TRN") to get the correct page to link to when you import the main page/table. Depending on whether you need to display the link codes, you can hide or even drop the field in the support templates. I'm assuming most support tables will be relatively simple and a template with a title and one extra field for the db id code should be sufficient.
  8. I don't think that's something to be solved in a completely straight-forward way, as PW's i18n functions weren't built for such a use case. I can see two possible approaches: Save the user's current language, then in the loop set it to the current language before assigning the value and restore the saved language afterwards - likely not advisable though, since all kinds of things happening in between (like messages or hooks) would also see the changed language. Or: Write a function to determine the appropriate text domain string like the original __() function in core/LanguageFunctions.php does, then use $lang->translator()->getTranslation($textdomain, "all day long", '') - though also not what I call trivial. Perhaps someone could come up with an easier solution to the underlying requirement if you outline why you want to fill fields this way, though.
  9. Literally thousands of tables or just thousands of rows/records?
  10. Oh, and it also reminds me of my most favorite "inheritance" at work. Someone, long before I joined the company and no longer available (their luck!), created an Approach database for test run data, and I was asked to "import it into a real database system and make it work offline". It had a few tables named X123 or X345 so you could easily identify their contents. Not. Every table had fields with descriptive names like F1 to F98 or B1 to B45, etc. It also had lots and lots of formulas on the form fields, using expressive variables named a, x, ab, ac... you get it. To make matters not too easy, the database fields could contain different semantic data depending on what kind of machine the report was for, i.e. what form was used to enter the data, and not all forms limited the accessible rows accordingly. Formatting of values was done by copying them back and forth between the database and hidden fields on sometimes unrelated forms. This was still something I could wrap my head around to a degree, but I soon discovered (by trial and error with a copy, since the code was bound individually to each of the 300+ form fields) thrilling little rules like "If the report is in German, then field F68 contains the description of the setup and F92 contains the English translation, but if the report is in English, F68 contains the internal addendum and F70 contains the English setup description, and the German translation can be found in F69." A true blessing when you want to use a standard reporting package to generate the PDF output. And did I mention that the charset could differ between rows without any indication in the data or record metadata? It think this was the first time that I had actual tears in my eyes after looking at a piece of software.
  11. Nice article. Made me remember the good old days of Perl golf.
  12. Good to see I'm not the only one scratching my head over the current jQuery-is-bad movement. To me, wiring in a full-fledged MVsomething framework only makes sense if the complete data exchange is abstracted away, otherwise backend code and frontend (speak backend UI) logic will get even tighter bundled (or bungled?). This would mean that all backend calls would need to be some kind of RESTful using JSON, XML or something along these lines, and plainly, PW isn't at that point right now and getting there would need quite a bit of work. I'm not a real wiz when it comes to MVC/MVVM frameworks, but I do have some experience building complex RIAs, starting by building everything on top of ExtJS (2 and 3) in the good old days and later rolling my own two-way bindings for nested data structures. I've recently delved a bit into the currently trending frameworks, and I was utterly appalled by the unnecessary complexity, semantic mumbojumbo and lack of essential features each of those exhibited in varying degrees. Don't get me started on the massive breaking changes introduced in major frameworks I see every year. I've got one really complex app that needs a larger overhaul next year (warranted after 8 years, I feel), and I've come to the conclusion that it will be simpler, faster and more concise to build everything without any framework besides a lean CSS library and perhaps jQuery, especially if I want it to run the following 5+ years without finding myself using an orphaned framework. If the PW backend could be completely JSONified, I'd be all for that, but even then, I'd currently prefer a framework-less default interface. Any MV* solution could then be an alternative, just like current admin themes.
  13. Why not use a repeater field with title and body instead of one single CKEditor field? You could then just iterate over the repeater items, render the anchors when outputting the titles and then iterate again in your TOC to render the links.
  14. You need to have at least one image field on the template, then you'll see an "Upload Image" button on the insert image dialog.
  15. I could reproduce the problem with a clean install. It seems that all event listeners on the page list select items get attached twice. I didn't have time to check with different browsers though. I might be able to do some more digging tomorrow when I'm back at work.