elabx

☝️ 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();

This has happened to me on some big PW version updates, but I honestly don't have much more info as to what could trigger this ?

You can use AdminOnSteroids to enable this on the text fields you need them, it's super handy, no need to install justify plugin or configure each field!

And some background on why you built this would be really interesting too! Looks great!

@LuisM wow great breakdown! thanks for all this info!

Maybe using a PageTable field to edit child pages right there on the field?

I've used this library with success to import products or update them regularly like on a cron job: https://github.com/donutdan4114/shopify Takes care of rate throttling too which is nice!

https://maquiladorademuebles.com/ Here I did a very rough integration of the Shopify Js SDK with ProcessWire, so that I could add more specific things to each product, when I talked to the client it was more important to have the potential to have more flexibility when uploading the product's content so we went this way of using Shopify inside PW. My first mistake was rolling my own Js integration when I could have just used the Buy Button SDK (instead I used the Js SDK with Vue). Second mistake. One thing I didn't anticipate that turned into a mess: discounts. I had to setup fields in Pw where I had to set the discounts (after setting them up on shopify), so a lot of double data entry on some cases. I've done also things the other way around, setting up ProcessWire as an application that launches within Shopify, so that I could use PW pages as extra content management for Shopify product pages. (very complex product descriptions) unfortunately the project I did this for never launched. Agree with @Pixrael the Shopify API is really easy to work with.

It's not built out of the box, but you could easily build a Process module, and render the forms you need using the formbuilder API you'd normally use on the frontend.