elabx

Was thinking more of these, because I've seen all the github issues.

I'm going to die if any of the hosting providers I use suddenly flips the switch to mysql 8 lol

Well its just a simple listing of content, I basically I was just wanted to give RockFinder a shot to see if it performed faster and it does! Basically brings down the time to nothing. Took a dive into the code and notice how you strip down the SQL select, I am guessing that's why it peforms faster since the original db query includes SQL_COUNT_FOUND_ROW. So, I'm starting to think I have no way to solve this without counting? Unless I make a prev/next pagination only maybe? Of course, I can always cache all of this, but just wanted to see if I could squeeze out a bit more of performance from the raw request.

Question, how do you go about rendering the paginator with RockFinder3?? I am testing on a table with about a million pages, and it indeed loads each page (as in paginated page) super fast! BUT, I can't seem to figure out how to actually render the paginator. I'm going to take a wild guess that the counting is going to take a long time.

There is a sort property on pages that can be set: https://processwire.com/api/ref/pages/sort/ So most likely you'll have to use the callbacks in UIkit to sort this out ?

Got this working on your codepen: var accordions = $("[uk-accordion]"); accordions.each(function(index, item){ UIkit.util.on(item, "beforeshow" , function(e){ accordions.not(item).each(function(index, item){ var opened = $(item).children('.uk-open'); var openItemIndex; if(opened.length){ openItemIndex = opened.index(); } if(openItemIndex !== undefined){ UIkit.accordion(item).toggle(openItemIndex); } }); }) });

Isn't that the default behaviour of the accordions? That's what it would seem like from the examples on the page, the component has a "multiple" option that is set by default on false. Maybe you need to update UIkit? EDIT: Just re-read, that it's ANOTHER accordion. I'd try something like this, just wrote it on the fly so there are probably errors, but the idea is to close any other accordions with the component's API, rather than adding/removing classes. var accordions = $('.uk-accordion'); accordions.each(function(index, item){ UIkit.util.on(item, "show" , function(){ accordions.not(item).each(function(index, item){ var opened = $(item).children('.uk-open').index(); UIkit.accordion(item).toggle(index); }) }) })

There's gotta be some CSS file loading (if the site has any actual styles), check your Network tab on chrome to check what's loaded, also if you inspect any element it should indicate the style's source. Otherwise, it might have been output right into the html body.

☝️ I'd love to help while learning! In my personal experience Fieldtype/Inputfield development is like one of the few things of the modular approach of ProcessWire that isn't completely clear to me, so I think a tutorial would be super useful for a lot of people. I'd like to stop abusing RuntimeMarkup some day haha (which is and awesome module of course!)

Could post a brief code snippet of what you are trying to do? I am assuming you should have something like this: On _main.php: <footer id="footer-region"> ... </footer> On other_template.php <div id="footer-region" pw-append> <script>...</script> </div> @huseyin Just to give my personal opinion, I just really like that with markup regions you can code the markup pretty much like if you were doing normal template output, no string concatenation to fill up a variable to output content, instead of doing that you wrap your markup with the Markup Regions conventions. That would probably be the downside, that you have to understand that maybe not all markup visible in your code, will actually end up in the output markup (depending on how you use it!), and this has sometimes caused me confusion while coding, but nowadays I practically code all my templates with markup regions strategy. So in conclusion, I see it more as a "style" rather than something better or worse.

This should work fine! After the include, API variables like $pages should be available, letting your grab whatever content you are managing with PW.

¡EXACTLY! I'm already exhausted thinking it's being done by one person (?) lol

The module from @kixe uses Spectrum jquery color picker and it has an option to show only a palette. https://modules.processwire.com/modules/fieldtype-color/

Mmm, yeah unfortunately that's not doable in AOS! There might be a hook somewhere to overwrite that just beforehand, but I'm out of answers for now. I think you'll have to install the Justify plugin, it's also not that troublesome.

Just came here to say this module works perfect up to date, testing on 3.0.148 ?. Thanks @Soma!

Piece of cake with ProcessWire I say ?! Registration with LoginRegister Pro, feedback/rating with comments module and probably I'd think of an admin dashboard or someway to present comments/rating in a nicer way than just going to the video page and look at the fields.

Gonna try this ASAP. Thanks!

I think it depends a bit on how you display the data. I'm doing a 2+ million pages and I'm struggling a lot with queries. But displaying pages of the data is not that bad. Searching on one field, such as a title field is somehow fast (a 5- 10 seconds). Trying to do something like the following can be really slow: $pages->find("template=blog_post, page_reference_field1.title|title|page_reference_field2.title%='something I want to match'"); I'm using a lightsails erver 2vcpu, 4gb ram. Don't really know if using a dedicated db server would help.

This could probably be solved by using this module: https://modules.processwire.com/modules/schedule-pages/

The site will mostly be cached with ProCache so I'm hoping CPU usage will only be heavily used when making the first import run. I'm planning to do about 3-6 million pages. Not entirely sure of the spike costs cause I'm not relly handling hosting payments. UPADTE: I don't know what the heck happened but now the script is performing ok with no memory spikes :S

Just tested both and I still see the memory go up and up :S Weird thing is the original setup just works okay on local even tested on another server previously and worked fine, it was all since I set it up in the AWS Ligthsail VPS that it failed, that's why my initial thought was some mystery php.ini setting. Even stripped down the script to the bare minimum to discard something else I was not seeing. Anyway, will keep on looking.

Hi! I am iterating through a very big CSV that check for existing pages on a PW installation . This all works fine on local development and if the records already exists in PW, I basically skip to the next iteration. This was initially causing memory issues until i added a $pages->uncacheAll() method, which cleared the result of the $page->get() from memory. Note, this is running through a CLI script. foreach($csv as $i => $record){ echo round(memory_get_usage(true) / 1048576.2) . PHP_EOL; $selector = "template=property"; $existing = $pages->get($selector); if ($existing->id) { $pages->uncacheAll(); continue; } } Unfortunately on the AWS Lightsail VPS I'm using, it doesn't seem to matter and memory usage just keeps growing. Am I missing some setting on PHP configuration maybe? I already checked the memory for the CSV iteration only (using PHP League CSV library) and it keeps memory in a fixed value (pretty much how it happens locally while iterating and using uncacheAll() to clear memory). Adding gc_collect_cycles() doesn't seem to do anything either.

Just in case someone stumbled into this, this command worked for me: sudo chown -R bitnami:daemon /opt/bitnami/apache2/htdocs sudo chmod -R g+w /opt/bitnami/apache2/htdocs

What type of field are you using to display the video? Were are you planning to server the videos from? Maybe give us a few screenshot of your template/fields configuration.

Yes, save the page! $testpage->of(false); $testpage->save();