Leaderboard

Happy to announce Blog 2.4.1 is now available for testing on the dev branch. Please test and let me know that it works OK, all the way from install to uninstall and everything in between, thanks. This version is highly refactored, brings in a new cleaner UI (at least I think so), including better sorting of posts/categories/tags, author bios, category description (not sure many know that categories have a field for entering descriptions), etc and one new (frontend) option that enables the control of the 'edit' link that appears for logged in users when viewing a Blog Post. The link can now be placed at the top, bottom or switched off altogether (@thanks to antoiba86 idea). Here are a couple of screens. I have tested in 2.7.2, 2.8.35 and 3.0.42 and everything seems to work fine. However, further tests are needed before I commit this to master. That's where you come in, thanks.

I completely understand your concerns regarding giving a client a product that you don't have faith in, but there should be no way a client can make this happen - they should not be given superuser access and therefore should not be able to install modules. I made exactly the same argument as you some time ago I just forced the same error in PW 3 (by deleting a language field in the pages table) and it now looks like this, with everything still accessible. I would definitely urge you to try PW 3 - there has been well over a year of development that's gone into this new major version. I think it is only fair that you judge PW based on this version - I hope you agree!

What's the thing you do not understand ? Did you tried to follow this post ? There are another example: A tutorial where you can took inspiration for processing your form : And a ton of references there: https://encrypted.google.com/search?q=processwire+contact+form

"how to store it inside processwire" - I am not sure what you mean here - do you mean save the content to PW pages? You can query content from an external database and simply iterate over it and output in your template file. Here is the docs on $database: https://processwire.com/api/ref/database/ Here is a rough idea of what you can do. Obviously I am querying the PW "pages" table, but you can do this on any table in the database whether PW or not. You can see in the output that you can easily iterate through each row in the returned array and grab whatever array keys (db fields) you want.

You can also have a look in my module http://modules.processwire.com/modules/fieldtype-select-ext-option/ This is a Select Fieldtype (single or multiple) which provides all the data of the selected table rows of any PW or Non-PW database table.

Thank you so much @flydev I end up worked with first two link you gave me I managed it work Thank you for your guys patience for newbies...

I do not use this module but these mods are looking great. How about adding the labels to the left of the fields? that would make the form look less crowded and easier to overview. I'm not sure whether the markup allows easy style update.

Here are some preview screenshots from my pimped out version of this module... 1) Added the placeholder and collapsed attributed to the fields editor: 2) allow export of the fields setup, as well as restore, so that you can take huge sets of fields and import them into a site. 3) ability to export/backup the settings values themselves, as well as restore them from backed up json. still need more testing, but so far these things help make this module more usable; also i changed the default global api variable to g_settings, to avoid the conflict with Lister Pro.

Less fields is better for you - less to manage, but it won't matter to PW either way because all the field db tables (eg field_slider) are indexed by the pages_id so PW finds the relevant entries very quickly. Having a separate field won't improve this.

As I mentioned - I think this may have been due to a change in the default settings of MySQL in more recent versions. Surely you can understand that 2.7 was working at the time when most of us were on older versions of MySQL? Out of curiosity, I googled Drupal and Wordpress along with the "column not found" error and found many results. Not trying to make excuses - just saying that this is sometimes the reality of software development - things break due to changes in dependencies - there are a lot of combinations/permutations to keep up with!

@kongondo Seriously this is an awesome job, I use the blog alot and this looks really clean and 'lit'. Can't wait for the new UiKit however would there be a guide to other devs so their Modules looks clean with the new UI

I might have answer to my own question. Posting for others who are new to PW. In Module->Configue->LanguageSupportPageNames, at the bottom there is a collapse select which I didn't initially see: Default language homepage URL is same as root URL? Choose Yes if you want the homepage of your default language to be served by the root URL / (recommended). Choose No if you want your root URL to perform a redirect to /name/ (where /name/ is the default language name of your homepage). Selecting No solved the issue as far as I can see

my two cents: I usually describe it as a CMF (content management framework) with build-in CCK (content creation kit)

Thanks for sharing. You also might want to check out ProcessLinkChecker by @teppo. I've not used it extensively, but it spotted some dead links (internal/external) on several websites.

@Jozsef There is no need to ask the same question twice. You already asked this same question in Fredi's support forum here: I'm moving your post there. One, because Fredi has its own support forum and two, multi-threading is not allowed.

wow - looks amazing!

Rather than trying to hack the url for file_get_contents, you should use ->filename instead and then you can just do: file_get_contents($page->icon->filename);

Testing this a little further. Stock Install, Debug off. Default Advanced Profile. MAMP PHP 5.6.10 / OPC off PW2 Boottime: ~120ms PW3 Boottime: ~80ms PW2 Rendertime Home: ~30ms (start of init, end of _main.php) PW3 Rendertime Home: ~36ms (start of init, end of _main.php) PW2 TTFB Chrome: ~170ms PW3 TTFB Chrome: ~240ms Not sure why the TTFB is so much higher.

Out of curiosity, are you using Apache or Nginx? And which version of PHP? Are you using MySQL or MariaDB? And which version? Edit: From which version did you update/upgrade (and how: upgrade module, directory and file replacements via FTP...)? Or is it a direct installation? Are you using it on Linux, Windows, Mac? Is it on a "localhost" or an online server? Is it via virtualization? How did you install it: direct download, git, hosting (c)panel...? Have you imported the database from another installation in a different environment?

@Beluga, I think the ImportPagesCSV module should be able to handle 35K rows with the right PHP settings. Ryan has talked about needing to split into batches above 450K rows (!) so 35K should be no problem.

The module does not allow for any Parsedown settings to be set in the module config, so you will have to copy the module to /site/modules/ and make changes there. If you use the Parsedown Extra flavour then you would edit line 70: $str = $extra->setUrlsLinked(false)->text($str); If you use the 'normal' flavour then do the same for line 62.

THX man, a worldfamous chocolate cake from vienna for you! Hero Member! Simple Contact Form - i do it tommorw, not so cool as the old version…

The "official" blog post about this topic might also be of interest: https://processwire.com/blog/posts/making-efficient-use-of-fields-in-processwire/ True, the word "performance" is not even mentioned in it, but I guess this is because this is not really about optimizing performance too much. Optimizing database access by means of proper usage of API calls and cache should matter the most.

Also made small test with Ryan's module. Were added 9359 ( 3119 per minute) pages in 180s before timeout.

Perhaps this could work in twig templates too - in ready.php add this: $view->bd = function($data) { bd($data); }; then use this in twig files: {{ $bd('hello world') }}

@gmclelland config.urls.root does not exist anymore. I also had this problem. Take a look at https://processwire.com/talk/topic/808-variable-for-domain-name/?p=93034

Yep - it will work on all servers - it will always be the full disk path to the image, which is what file_get_contents wants. Of course with the right PHP settings it can also use a full URL, but disk path is easier and more universally supported.

I just did a quick test with BCE using your test file and by the time it hit my 120 timeout, it had created 4898 pages, so 2449 pages per minute isn't too bad. Curious what you find at your end though.

Might be as simple as file permissions - do a recursive 755 / 644 (or whatever is appropriate) and make sure the owner is correct, eg www-data:www-data

I somehow managed to delete the original post here when editing it . Rather than rewrite it here, and since it was to feed into a write-up in the Media Manage docs, I might as well write it there. So, that's what I'll do. I'll find some time today and write that, er, write-up. I'll post a link here afterwards...

I don't want to sound too defensive here but PW gets a pretty decent amount of usage, from 'simple' sites to things quite more complex. If it were to break down often after performing common actions i don't think it would still have such a sizable following. In fact, i would say that PW is pretty damn stable. I understand that the admin becoming inaccessible is a frustrating and undesired experience but is has been addressed in more recent versions. I think you're a little quick in doubting the quality of PW's development.

1) The default behaviour in PW is, it would be added if you save with status unpublished. If you save and publish it will be removed. 2) You are right and I have to correct myself there will be no changes later if you use both: force isPublic() to return false and setting $config->pagefileSecure = true; The problem is ProcessPageView::sendFile() as I mentioned here. A new header will be created and passthru the .htaccess settings. So you need to hook in ProcessPageView::sendFile() too; /** * Passthru a file for a non-public page * * If the page is public, then it just does a 301 redirect to the file. * */ protected function ___sendFile($page, $basename) { }

Hi Guys I needed a Link Checker to find broken links on my processwire websites. So I searched and came across this tool called Integrity. I've tested a little bit und must say it is a very good piece of software. fast and free Nice clear UI Only available for Mac OS There is also an alternative mentioned on the Integrity Website for Windows User called Xenu's Link Sleut. Hope this helps at finding Broken Links on your websites. Greetings Orkun

I haven't used this module, so not sure about those red fields, but I think the likely correct fix for the operator not supported issue is to to define $allfields in the additional fields at around line 65. protected $allFields = array();

The problem occurs because the "user" template is a system template. See this comment in PageRender.php: Specifically setting prepend/append files in the Files tab of Edit Template doesn't work either - you might need to use an include for _init.php in user.php.

Surely if it's a count operation then you could just subtract the number of pages that need to be excluded - no need to add them to the selector. Or is count() just an example and you do actually need to return the pages?

Actually I take that back - the function (and therefore the db query) won't be called unless you call $page->courseData so no need for this.

You will likely want to add some sort of conditional inside that AddHookProperty to check the template of the page so you only run the query on appropriate pages. eg.: if($event->object->template == "template_that_needs_course_data") {

You can add a hook like this in your /site/init.php file: $this->wire()->addHookProperty('Page::courseData', null, function($event) { $sql = "SELECT * FROM ......"; $results = $this->wire('database')->query($sql); $event->return = $results->fetchAll(); }); And then in your template file you can call: $page->courseData You can also make of $event->object->name inside the hook to get the name of the page that the courseData property is called from so you can use that in your sql query. Of course you can get any other field from the page, like $event->object->myfieldname and use that in your query as well. Does that help?

related stuff: If you just want to update $page->of(false); $page->status = 2049; $page->save(); $page->status = 1; $page->save();

The name property is not translated, it is a unique identifier for a page together with the parent_id. You should not build urls manually like this, you should use the following method: $page->localUrl() See: https://processwire.com/api/ref/page/ Edit: The name is translated as well, but calling $page->name always returns the (unique) name of the default langauge. Use $page->localName() to get the translated name of a language.

Keep in mind that there a are other better ways to achieve this. You should read this tutorial made by @kongondo : Anyway, to continue with the repeater and to add tags to your aforisms you could create a new template "aforisms_tags" and a page in the PageTree called "Aforisms Tags", assign the template "aforisms_tags" to this new page; And add some children to this page: tag1, tag2, tag3... Then you create a new field of type PageReference , set the option Input Field Type to "AsmSelect" and set the option Parent to the new created page "Aforisms Tags". Then you add the field to your "aforisms_repeater". Illustration : There is the code : $aphorisms_list = ''; $tags = ''; foreach($page->aforisms_repeater as $aforism) { $aphorisms_list .= "<li>"; $aphorisms_list .= $aforism->aforisms_title; foreach ($aforism->aforisms_tags as $tag) { $tags .= "<span class='tag' style='margin: 3px; color: red;'>"; $tags .= $tag->title; $tags .= '</span>'; } $aphorisms_list .= "{$tags}</li>"; } $content .= "<ol>{$aphorisms_list}</ol>";

The other day I saw a post about a one man passenger drone going to fly as a taxi in Dubai. You want it real cool ? Here you go: zapata one man flyboard with unbelievable manoeuvrability and portability. Many thought that this is faked with after effects or a hoax but this is for real. He developed this flyboard out of his huge expierience with his waterjet powered jetskies. Kerosine fuel is stored in his backpack wich gives about 10 minutes flight with max 90 mph This is the green goblin coming into reality One of his flights https://www.youtube.com/watch?v=deyMNPbaRpA Some explaining https://www.youtube.com/watch?v=x1CfhQnlZAU

Marc, it sounds like you've got a bottleneck somewhere. You mentioned a remote DB connection, and maybe there's something to to that. You also mentioned Windows (I'm in unix), and it's certainly possible there's something platform specific going on. Here are some things you can do to narrow in on where it might be. Edit your /index.php file and before the line that says this: $config = ProcessWire::buildConfig($rootPath); Add this: Debug::timer('pwboot'); Now edit your /site/templates/_init.php file (or whatever gets called first) and add this at the top, after the "namespace ProcessWire;" (old school and rough, but gets straight to the point): die('Boot time: ' . (Debug::timer('pwboot')*1000) . ' ms'); Now you can get a sense of how long it takes ProcessWire to boot, before it hands off the request to you. This should give you an indicator as to whether you need to look at the modules you've got installed, or whether you need to look at the API calls in your templates. Hit reload several times in your site (front-end) to get a sense of the average boot time. On my oldish Macbook Pro and PHP 7, running the site-default profile with no 3rd party modules installed, these are my average boot times: ProcessWire 3.0.52: 53 ms (opcache off) ProcessWire 2.7.3: 104 ms (opcache off) ProcessWire 3.0.52: 35 ms (opcache on) ProcessWire 2.7.3: 35 ms (opcache on) As you can see, without PHP caching the code, ProcessWire 3.x boots nearly twice as fast as ProcessWire 2.7 (at least in my environment). Interestingly, if PHP's cache is enabled, then the boot time is identical. But when Soma said above “ProcessWire is getting slower and slower each iteration”, this is a blanket statement that is the opposite of reality. ProcessWire is getting faster and more optimized with each version. What's real is that clearly something about the conditions present in his environment and your environment is reducing performance, and that needs to be narrowed in upon. So the next steps will be to determine if it's something about the server, something from a module, or something going on in the template file(s), like some specific API call that might be common among your installations. Now go to your Chrome dev tools, Network tab. Hit reload several times like you did before (same URL). Note the first request in your Network tab. Take this time and subtract the time you recorded above. This represents (roughly) the time required to load PHP before it gets to ProcessWire. With opcache off, my PHP takes about 100ms before it loads ProcessWire's /index.php file. If I enable opcache, then I'm seeing almost no overhead from PHP at all. Meaning, Chrome dev tools is showing 40ms or less. I'm guessing that your remote DB connection is going to mean your boot times are significantly higher than if it was local. So maybe you shouldn't be looking for the same boot times that I'm seeing here. But hopefully you can get a better idea of whether the times you are seeing are related to the boot process, or what happens after the boot process. If you are seeing it in the boot process, then uninstall all 3rd party modules and test again. Or go one-by-one until you can narrow in on which one it is. If still seeing a slow boot then we might need to start looking at potential Windows platform issues. If your boot times seem reasonable, then the next step is to start debugging in the template files. Let me know what you find and I can suggest the next steps.

Welcome to the forum @Cengiz Deniz About your question, you could use a Repeater for the aphorisms in your template. First read this doc : http://processwire.com/api/fieldtypes/repeaters/ , you should get an idea on how repeaters works. So for your example, you could make a new text field called aphorism_title and a new repeater called aphorism_repeater. Finally you add the text field 'aphorism_title' to the repeater. You should end up with something like that : In your page template, you add the repeater field you just created, and add some aphorism to it : Then in the template code, a simple foreach loop will do the job to show all the aphorisms in a list: <h3>ÖzlüSözleri</h3> <?php $aphorisms_list = ''; foreach($page->aphorism_repeater as $aphorism) { $aphorisms_list .= "<li>{$aphorism->aphorism_title}</li>" } ?> <ol> <?php echo $aphorisms_list; ?> </ol> Hope its clear enough, you can adapt it depending the output strategy you use, but do not hesitate to ask more information. Good luck!

For any Windows developers interested in an easy way to get going with Docker and Processwire that includes local debugging... https://github.com/rastographics/pwocker Local debugging in your IDE with Xdebug pre-configured. (Also includes working launch.json for you VS Code users ) Use *.localtest.me hostnames for each site you are developing (no editing of hosts file) Simple configuration...copy 2 files into your project, edit a couple variables in those files, and run 1 command per project. Tested with Docker 1.13.1-beta42 on Windows 10 Pro 64-bit. I didn't know much at all about Docker, nginx, or xdebug before doing this, so I pulled much info from gebeer's work and many others who have put Docker/PHP/xdebug stuff out in the community. And it may not be the best setup ever, but it finally gives me what I needed for doing PW work on Windows in a true Linux stack with IDE debugging.

@Juergen: At the cost of a couple of extra DB queries, you can use my new favourite tool Paginator: (thanks @LostKobrakai) include 'src/Paginator.php'; include 'src/PagesPaginator.php'; $paginator = new PagesPaginator(); $result = $paginator(array( "headline~=$q", "introtext~=$q", "body|whatever~=$q" ), $input->pageNum, 25);

Excellent write-up Ryan! Here's a quick tip. If you are processing large amounts of data, you should always use PW's field joining options to achieve maximum performance. Even if you only use a single field, you should get around 50% faster execution when the field is joined straight away. With two fields joined, the execution time will be cut into half (i.e. 100% increase in speed). Let's say you need to export the e-mail addresses of thousands of customers. Here's a simplified example using "on-demand" join // Prepare a pointer for writing the output $fp = fopen('customers.csv', 'w') or die('Failed opening the file for writing'); // Ask PW to join two fields (the regular find() also supports this). $options = ['loadOptions' => ['joinFields' => ['customer_email', 'customer_number']]]; // Searching for imaginary customers $selector = 'template=customer'; // Find the pages using the new method foreach($pages->findMany($selector, $options) as $page) { // Write the data in CSV format fputcsv($fp, [$page->customer_number, $page->customer_email]); } // Free the pointer fclose($fp); As a reminder, you can also force some fields to be always joined (through PW admin). @Joer: That is pretty much what the implementation of findMany() does behind the scenes. However splitting the job into smaller batches still makes sense if you use multiple workers to process the data (e.g. for MapReduce or whatever) or if the execution time of your script is limited.

New version 0.1.2 * fixes CSRF token validation (Thanks!) * adds option to overwrite email message * adds "from name" for generated email * allows multiple recipients

This should do it throw new Wire404Exception();