Leaderboard

This week we focus in on a new and unique Inputfield module added to the core that enables a lot of useful new input capabilities for tags, sortable multiple selection and custom user input. I introduced it in last week's forum post, but it was further improved this week and reached a point where I thought it would need some dedicated documentation, so this post dips into that and goes quite a bit more in-depth than last week’s. I never got around to bumping the version to 3.0.176 because the module wasn't quite done till Thursday (kept updating with improvements), but just in case there's any confusion about versions between last week and this week, I bumped it to 3.0.177 even though it contains what was originally intended for 3.0.176, plus more— https://processwire.com/blog/posts/pw-3.0.177/

Two things came into my mind, if I get it right what you are after. (not totally sure): You may create a "custom user page" as regular page after each successful registration. You only need one extra field in native user pages that stores the page id of the bundled custom user page. This way you can use the built in users and roles system for all login and access related and have all other stuff in a regular page with templates & fields of your choice including all regular api related stuff. (For accessing pages that should not be public, you also may hook into viewable etc. and check if the $user->isLoggedin() and if the $user->custom_field_id matches the id of the custom-user-page that is tried to be accessed.) ------- Regarding unique URLs I used a lot something like the following: $loginToken = bin2hex(random_bytes(30)) . md5(time()); // store this once into a dedicated field of the custom user page on registration https://www.php.net/manual/en/function.random-bytes.php I think the random_bytes already should be enough, adding a timestamp may be a bit superstitious or overanxious. ?

This is just a quick info that I've built a little module on top of @David Karichs great PageHitCounter to store and present historical data of page views. Note that "historical data" means it can display all pageviews from the time this module has been installed. It can NOT show statistics from before that point of time! It is by no means meant to replace a full analytics software, but for simple sites this might be just what you (or the user) need(s). I release it as imperfect as it is for two reasons: Even if the presentation of the data is not perfect yet it might make sense collecting statistics sooner than later. If anybody wants to work on the presentation side I'd happily merge PRs (or if anybody wants to sponsor updates... PM) Presentation is done by plotly.js in conjunction with the awesome tabulator.js (both loaded via CDN at the moment) - that means easy analytics can already be done by using tabulator's internal filter capabilities! Please see the readme for important notes! https://github.com/baumrock/RockHitCounter

Hi, I have a page template for products with multilang fields . And many such pages on site (around 20000) And i need to to display all products without translations on any used languages on any of those multilang fields (body, name, color, etc..) Is there selector of some sort to find those pages? Or iterate and manually check fields values for empty on every language is the only way?

Hello bernhard, this module looks great! It is exactly what I am searching for a small website. Thank you!

@Hector Nguyen getcsv() does return an array, but it is an array representing and consuming the memory of just one line from a CSV file (i.e. the columns from 1 row). fgetcsv() is just a layer on top of the fgets() function, which reads one line at a time from a file, which is what makes it memory friendly. On the other hand, PHP functions like file() or file_get_contents() do read the entire file in memory, so they are not memory friendly, even if they are fast. @fedeb I think the best route to take for your groupID+start+end+sequence would be a custom Fieldtype. This would give you all of the benefits of having a repeater, and without any of the overhead. Custom fieldtype may sound complicated, but it's not at all. I've developed a module that can very easily be adapted for this need. See FieldtypeEvents which was created as an example to build exactly this sort of thing from. If you are interested in that route and have any questions, I'm happy to walk you through it.

Hi, Thanks a lot for all the feedback. I did some additional tests based on all of the suggestions you gave me and results are already amazing!! Figure 1 shows @ryan suggestions tested independently: 1. I created the $template variable outside the loop. 2. I created the $parent variable outside the loop. The boost in performance is surprising! Defining the $parent outside the loop made a huge difference (before I didn't assigned the parent explicitly, it was already defined in the template thus the assignment was automatic) 4. I also tried this suggestion ($page->name = "protein" . $i;) and although it seems to boost a bit performance I didn't include the plot because results were not conclusive. Still I will include this in my code. Figure 2 is based on @horst suggestion. I tested the impact of calling gc_collect_cycles() and $pages->uncacheAll() after every $database->commit(). I didn't do a test for $pages->uncache($page) because I thought $pages->uncacheAll() was basically the same. Maybe this is not true (?). Results don't show any well defined boost in performance (I guess ryan's recent reply predicted this). I still need to try @BitPoet suggestion because I am sure this is something that will boost performance. I am now doing this tests on my personal computer. I will do this test when running on the dedicated server. I will also would like to try generators (first time a hear about them ) ______________________________________________________________________________________________________________________________________________________________________________________________ One last thing regarding the fields in the protein template and the data structure in general (the pseudo code I posted initially was just as an example). Proteins are classified into groups. Each protein can belong to more than one groups (max. 5). My original idea was to use repeaters because for each protein I have the following information repeated: GroupID [integer], start [integer], end [integer], sequence [text] The idea is that from GroupID you can go to the particular group page (I have around 50k groups) but I don't necessarily need a page reference for this. The csv is structured as follow. Note that some protein entries are repeated which means that I shouldn't create a new page but add an entry to the repeater field. Protein-name groupID start end sequence A0A151DJ30 41 3 94 CPFES[...]]VRQVEK A0A151DJ30 55 119 140 PWSGD[...]NWPTYKD A0A0L0D2B9 872 74 326 MPPRV[...]TTKWSKK V8NIV9 919 547 648 SFKYL[...]LEAKEC A0A1D2MNM4 927 13 109 GTRVW[...]IYTYCG A0A1D2MNM4 999 119 437 PWSGDN[...]]RQDTVT A0A167EE16 1085 167 236 KTYLS[...]YELLTT A0A0A0M635 1104 189 269 KADQE[...]INLVIV Since I know repeaters also creates additional overhead I am doing all my benchmarks without them. I can always build the websites without them. In the next days I will do some benchmarks including repeaters just to see how it goes. Once again, thanks for all the replies!

A little more to the back story... Client's biggest target audience is children's parties hence the look. The only time I said an absolute "NO" to client was when client said use "Comic Sans" font. There are some boundaries I will not overstep! Heading font is Google 'Happy Monkey'. ?

The relative dates will come via WireDateTime::relativeTimeStr().

Cool. On a related note: If you need to extract images from an MS-Word file, there's an easy "hack": Copy the Word file rename it to filename.zip. Un-zip it, and you'll see a folder "media" with all the images inside