FlorianA

Members
  • Content count

    12
  • Joined

  • Last visited

Community Reputation

4 Neutral

About FlorianA

  • Rank
    Jr. Member
  • Birthday November 8

Profile Information

  • Gender
    Male
  • Location
    Northern Germany
  1. After some further thoughts I wonder if it is a good idea to activate the Multi-Language URLs at all for my site. I have a lot of pages that will probably never be published in an other than the default language, but users with other languages should see untranslated pages nevertheless in the default language - without any additional effort for the page author. Would it be a solution for this to leave the multi-language URL module away and keep only the multi-language fields? One URL for all languages would be sufficient for me. Are there any other drawbacks with this approach?
  2. While it's generally a good idea to avoid globals in PHP I'm wondering what is the easiest way to access the PW API variables like $page, $user, $fields etc. from a function body within a template file. I would like to understand them as a kind of "superglobals", so I find it tediuos to pass them as parameters to every function that needs them. On the other hand, I haven't found a solution to access them as PHP globals within a function (with my humble PHP knowledge). Neither Jonathan's solution nor the $GLOBALS approach seems to work with PW "globals". Are there any best practices how to acces the PW API variables from a function?
  3. Thanks a lot @SiNNuT, it works! Would never have found it out myself - still seeing no API ...
  4. I have exactly the same problem, but I'd like to import my event pages by a command line script from another database. So I need to activate the language specific URLs programmatically, but I haven't found an API function to do this. Can anybody help me?
  5. No template? But a page without template isn't possible, is it? Currently I'm setting the 'entry' page's name to it's ID in order to avoid generated names (timestamps) which seem to be longer.
  6. Thanks a lot for showing me. Looks really nice on first glance, but unfortunately it doesn't meet my requirements completely, since the Matrix can only contain one string in each cell, but in order to port my current solution to PW, I also need for each cell (at least) a second string which holds an optional comment on just that single value a change date for the cell. A more specific type for the actual input value (boolean, number, selection), along with an appropriate backend editor would also be nice, but not essential, since the values could be stored as strings as well, and for editing I'll probably need a more user-friendly front-end solution anyway. After all, a page for each cell might be a not so bad solution. Maybe I can user something like the URL Shortener module in order to keep the names short at least ...?
  7. I've just extended FieldtypeTime and InputFieldTime by support for blank values Failed to add a push request to https://github.com/netcarver/PW-FieldtypeTime, so please find my patch attached ... Works fine at me. PW-FieldtypeTime-Empty-times.patch
  8. For my website, I need to implement a feature similar to Doodle: A table with a list of events as columns and a list of users as rows. The inner table cells show for each PW user at which events he can participate (btw. this "participate" need not to be simply a boolean flag, but can also be a selection (yes/no/maybe), a number or a string, along with a comment). In a classical relational database, this would be easy to implement as a many-to-many relation. With PW, I couldn't find a really satisfying solution so far. My current approach is to insert a page for each "participate" cell whose template has references to both a user and an event page. However, I think it's not really efficient to have a whole page for each cell. The pages will never be needed as an isolated unit but only as parts of other pages. There may be many thousands of these pages which would mess up the page tree in the backend. Each page has several additional fields in the underlying database which will never be needed but increase considerably the needed storage space: name, publish date etc. Maybe this implementation will nevertheless run smoothly in practice, but it simply feels quite cumbersome compared to the plain MySQL implementation of my previous website, so my hope is that there's a smarter PW solution for this. Can anybody give me some hints?
  9. Thanks a lot for the hint, Robin S. I've just joined the thread about the module, since it still has an issue with blank values ... (https://processwire.com/talk/topic/7857-module-fieldtypetime-inputfieldtime)
  10. Why don't you insert a NULL value for the time if it's left blank? This should work perfectly with MySQL. Apart from that, thanks a lot for the module, but the blank problem is also essential for me, so I really would appreciate a solution
  11. A field of type Datetime can be configured to leave the time away, for cases where you are only interested in the date. Unfortunately, I need the opposite: A time field without additional date. But it seems not to be possible to configure Datetime to leave the date away. Is there a possibility to do this? Or any alternative, e. g. a module? Of course I simply could use text fields for time input, but I would prefer the nice time picker and automatic input validation.