wishbone

On 5/16/2022 at 3:06 PM, Stefanowitsch said:

That is the usual way I do it (and I think most of developers do):

people often suggest to first do a new install and then copy the site into it.

Or even to use "one of the" migration modules.

But just copying everything works! so I think it's the easiest way.

thank you!! when I understood it's not a matter of the pw-install, I searched again - and I don't believe how easy it was: the database name was casus sensitive. I had the prefix in capitals: DB...

how many hours!

learnt also that it's ok to just copy all the files from local to remote without new install

thx again

I copied an install from local to remote. I just copied all the files, and of course imported the database.

Checked the database connection details in config.php ten times over.

Can't connect to the database.

On 5/10/2022 at 10:53 AM, wishbone said:

"General error: 1194 Table 'pages' is marked as crashed and should be repaired"

had an update from 2.2 to pw .199 with PHP8

...

Any suggestions?

I did an all new upgrading process, now works.

"General error: 1194 Table 'pages' is marked as crashed and should be repaired"

had an update with PHP8 and pw .199 which after some issues worked fine - until I tried to export the database.

See this thread:

Any suggestions?

thx!

don't know if this got to do with the install:

Tried to export the database. Got this notice (Firefox):

Quote

sql.part konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte (could not be saved, because the source file could not be read).

I did Firefox troubleshooting refresh.

Now even worse (in Chrome also):

Quote

Breaking news… Error: Exception: SQLSTATE[HY000]: General error: 1194 Table 'pages' is marked as crashed and should be repaired (in \wire\core\WireDatabasePDOStatement.php line 168)

#0 \wire\core\WireDatabasePDOStatement.php(168): PDOStatement->execute(NULL)
#1 \wire\core\WireDatabasePDOStatement.php(148): WireDatabasePDOStatement->executeDebug(NULL)
#2 \wire\core\WireDatabasePDO.php(894): WireDatabasePDOStatement->execute()
#3 \wire\core\PagesLoader.php(1087): WireDatabasePDO->execute(Object(WireDatabasePDOStatement))
#4 \wire\core\Pages.php(214): PagesLoader->getById(Array)
#5 \wire\core\ProcessWire.php(604): Pages->init()
#6 \wire\core\ProcessWire.php(561): ProcessWire->initVar('pages', Object(Pages))
#7 \wire\core\ProcessWire.php(314): ProcessWire->load(Object(Config))
#8 \index.php(52): ProcessWire->__construct(Object(Config))
#9 {main}

This error message was shown because: site is in debug mode. ($config->debug = true; => site/config.php). Error has been logged.

how to do this? The lines don't match.

thx!

as for now, no more issues

works! great! thank you so much for walking me through this.

I changed in config.php
$config->chmodFile = '0666'; to 644 and
$config->chmodDir = '0777'; to 755, is that correct?

When going to debug mode tools, I find this error with the old language tool (which I hoped not to have to change ? ). Works correct though:

Quote

Deprecated: mb_strtolower(): Passing null to parameter #1 ($string) of type string is deprecated in \site\assets\cache\FileCompiler\site\modules\LanguageLocalizedURL.module on line 174

wow!

works (as far as I can see at the moment) !

Only error: login failed

Quote

Deprecated: Implicit conversion from float 7.5 to int loses precision in C:\xampp\htdocs\ditib-ma-pw\wire\core\Password.php on line 249

where it says:

			// split the password in two
			$splitPass = str_split($pass, (strlen($pass) / 2) + 1);

or better use php7 to be on the safe side?

thx!

Yes you're right - PHP 5.3.8 (xampp 1.7.7)

Imported site, wire, .htaccess and index.php into another xampp install - 8.1.5 for windows with PHP 8.1.5 which throws these fancy errors:

Quote

Deprecated: substr(): Passing null to parameter #1 ($string) of type string is deprecated in \wire\core\PagesSortfields.php on line 98
Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in \wire\core\Selectors.php on line 1484

the latter repeated many times)

Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in \wire\core\WireArray.php on line 587

Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in \wire\core\WireArray.php on line 593

Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in \wire\core\WireArray.php on line 598

Part of the frontend can be seen through these errors.

Trying to log in gives these errors:

Quote

Deprecated: Return type of ProcessWire\WireDatabasePDOStatement::bindValue($parameter, $value, $data_type = PDO::PARAM_STR) should either be compatible with PDOStatement::bindValue(string|int $param, mixed $value, int $type = PDO::PARAM_STR): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wire\core\WireDatabasePDOStatement.php on line 126

Deprecated: Return type of ProcessWire\WireDatabasePDOStatement::execute($input_parameters = null) should either be compatible with PDOStatement::execute(?array $params = null): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wire\core\WireDatabasePDOStatement.php on line 144

Deprecated: Return type of ProcessWire\LanguagesPageFieldValue::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wire\modules\LanguageSupport\LanguagesPageFieldValue.php on line 302

plus the above errors

I'm lost.

Where did I go wrong?

Hi hello,

don't laugh pls, but I upgraded an old site from 2013, PW 2.2.9 to 3.0.184 via 2.7 - which went fine! just awesome.

Unbelievable.

Yet another reason to love processWire.

Only MarkUpSimpleNavigation doesn't show unpublished items. Otherwise works fine!

I have no errors in the logfile.

Only error I get is when trying to edit a field ** or a template ** (any):

Notice: Use of undefined constant JSON_UNESCAPED_UNICODE - assumed 'JSON_UNESCAPED_UNICODE' in \wire\modules\Inputfield\InputfieldTextTags\InputfieldTextTags.module on line 572

Warning: json_encode() expects parameter 2 to be long, string given in \wire\modules\Inputfield\InputfieldTextTags\InputfieldTextTags.module on line 572

but I guess this can't be the reason. (Since I'm a non-coder, I don't know what to do with this.)

omg, that's it! unpublished children don't show. (which is sensible)

Big thx!

yes, thank you, shows!

But why?

Why do old pages show without?

Anyway, now not published pages show as well.

very strange behaviour:
- pages created before work and render foreach data.
- new pages with the same template show header and footer and nav ok, but don't render foreach-data any more.
- foreach-data in the head-navigation is rendered ok.
- child pages (without foreach) work ok

I checked and compared all settings.
Must be a very stupid simple setting.
I'm confused.

Any idea, where else I could look?

this is the code for the template:

<?php

include('_head.php'); // include header markup

  foreach ($page->children as $child) {	
	echo "<section>";
	echo "<div class='contentWrap uebersicht'>";
	echo "<a href='$child->url'><h1>{$child->arbeiten_block->first()->headline}</h1>";
	if($child->teaserBildTh) echo "<p><img src='{$child->teaserBildTh->url}' alt='{$child->teaserBildTh->description}' class='bildNeben'></p>"; 
	echo "<p>{$child->arbeiten_block->first()->details}</p></a>";
	echo "</div>";
	echo "</section>";
	};

	include('_foot.php'); // scripts
?>;

thx!
 

On 3/19/2012 at 9:36 PM, Soma said:

Hi gottberg!

To include the root page you would pass the option "show_root" like:

echo $treeMenu->render(array( "show_root"  => true ));

 

sry, very old thread ? but this doesn't work for me, throws this error:

"Fatal Error: Uncaught Error: Call to a member function render() on null in site\assets\cache\FileCompiler\site\templates\basic-page.php:54"

found the code! In a post from 2011 ? thx to @BDH

Does exactly what I want: show the whole tree, but only render submenus of a current item.

Could have achieved that with css also, but semantically, not that clean.

Now I tried to prepend the homepage like this (before the "foreach"), but doesn't work:

$rootPage->children->prepend($rootpage);

What am I doing wrong?

Anyway, I don't understand the $s=str_replace thing - works, but as I'm trying to learn from examples, would be nice to understand what that is.

There are still two modules: MarkupMenu and Menu Builder - but they seem to be overloaded for this simple task?

On 1/24/2021 at 11:03 AM, Smirftsch said:

// if the item has children and we're allowed to output tree navigation (maxDepth)
		// then call this same function again for the item's children 
        if($item->hasChildren() && $maxDepth ) {
			if($class == 'nav') 
                $class = 'nav nav-tree';
            if ($maxDepth > 1 || $item->id == wire('page')->id)
    				$out .= renderNavTree($item->children, $maxDepth-1, $fieldNames, $class);
    			else {
    				foreach($item->children as $childitem) {
    				if ($childitem->id == wire('page')->id)
    					$out .= renderNavTree($item->children, $maxDepth-1, $fieldNames, $class);
    				}
    			}
		}

Same problem here: render submenus only for the current page.

Instead of Smirftsch's above, I tried the following (I have a non-$out-versionn of the RenderNavTree):

// if the item has children and we're allowed to output tree navigation (maxDepth)
		// then call this same function again for the item's children
		
		$currentItem = $item->id == wire('page')->id; 
		if(($item == $currentItem and $item->hasChildren())) {
			renderNavTree($item->children); 

and I call the function like so:

<aside id='sidebar'><?php
	
		// rootParent is the parent page closest to the homepage
		// you can think of this as the "section" that the user is in
		// so we'll assign it to a $section variable for clarity
// instead of $section, render the whole tree, beginning from the homepage
		$home = $pages->get('/'); 
	
		// if there's more than 1 page in this section...
		if($home->hasChildren > 1) {
			// output sidebar navigation
			// see _init.php for the renderNavTree function
			renderNavTree($home, $maxDepth = 2);
		}
	
		// output sidebar text if the page has it
		echo $page->sidebar; 
	
	?></aside><!-- end sidebar -->

only renders "Home" ? (I'm a non-coder anyway...)

On 4/8/2021 at 12:27 PM, kaz said:

Is the module not developed further?

PHP 5.6 is hardly supported anymore for many providers. It makes no sense (!?) to use tricks to start the installation. A question to the developer, what is the future of MarkupProcesswirePhotoswipe? Will the PHP problem be fixed upon backend installation?

Same question here. Was so happy to find a plugin for photoswipe. Even with "Petersburger Hängung" just great!
But since there are no answers to the PHP7.4 problem, I won't waste time to find out ?

it's a live site and that's why: I get that error now and not later, when everything is done and doesn't work on the server...

1 hour ago, wbmnfktr said:

Did you install it on the very same setup (on Strato) and maybe even with the same domain

cleared everything and reinstalled the intermediate edition (first install was blank edition) exactly the same way on the same place... which was easy and fast, only that error...

Hello again,

after I got the "blank" version running, I rather wanted to see the "Intermediate"-version.

Install allright - last step showed this error:

Warning: ini_set(): Headers already sent. You cannot change the session module's ini settings at this time in /htdocs/wire/core/Session.php on line 247 Warning: session_name(): Cannot change session name when headers already sent in /htdocs/wire/core/Session.php on line 251 Warning: ini_set(): Headers already sent. You cannot change the session module's ini settings at this time in /htdocs/wire/core/Session.php on line 257 Warning: ini_set(): Headers already sent. You cannot change the session module's ini settings at this time in /htdocs/wire/core/Session.php on line 258 Warning: ini_set(): Headers already sent. You cannot change the session module's ini settings at this time in /htdocs/wire/core/Session.php on line 259 Warning: ini_set(): Headers already sent. You cannot change the session module's ini settings at this time in /htdocs/wire/core/Session.php on line 260 Warning: ini_set(): Headers already sent. You cannot change the session module's ini settings at this time in /htdocs/wire/core/Session.php on line 272

though I can continue flawlessly, but I don't want to run into problems further on...

This topic https://processwire.com/talk/topic/22559-warning-ini_set-session-errors/ says something about PHP Beta version, but I run stable 7.4.

btw: everything is very well explained in these example versions, which is a big step forward to when I last used pw (2013 ? ) 

you are so kind! 

OT:

I actually haven't done many pw-sites, the first 2013.

I would like more users to use PW, but for wordpress users, e.g., it's too difficult, unfortunately. But only 1 example: when it comes to split menues (submenu on a different place than main menu), almost any other cms fails. Of course, for more complex sites, e.g. with collecting of data according to a property, you need more.

Anyway, nowadays clients want sites only in this "bootstrap style"; so page builders are fame, and customers don't appreciate individual looks. That's my experience, at least.

Who needs processwire, then? </rhetorical question>

And yes, that's not a matter of the underlying system but of the templates. But all the popular CMSes come with such templates. 
Which is, probably, the biggest manko that keeps WP users off PW. 

I would like to see PW used more, it's, even for me, so beautiful!

24 minutes ago, wbmnfktr said:

ProcessWire isn't perfect

Oh? I thought it was just PERFECT ? and even for a non-developer with no php skills what so ever it opens all possibilities - but only with help. After encountering those very small initial problems I would have already left pw - without your help.

17 minutes ago, wbmnfktr said:

you can either mark the thread or an answer as solution

 couldn't find it so I 

17 minutes ago, wbmnfktr said:

change the title to [SOLVED]

**update** can't change the title...

17 minutes ago, wbmnfktr said:

Don't know what you mean with this.

With this section removed, PW doesn't detect mod_rewrite:

  # 8B. Set an environment variable so the installer can detect that mod_rewrite is active.
  # -----------------------------------------------------------------------------------------------
  # Note that some web hosts don't support this. If you get a (500) error, try commenting out this 
  # SetEnv line below. 

  <IfModule mod_env.c>
    SetEnv HTTP_MOD_REWRITE On
  </IfModule>

17 minutes ago, wbmnfktr said:

ProcessWire has the best community from all! 

Without this help, a person like me wasn't able to use processwire.

thx everybody!

was my bad ?

I had the SetEnv deleted - thought it wouldn't be there any longer (thread is almost 10 years old ? ) when I searched for it (suggestion in above mentioned thread).

I'm happy to get help so easily!

btw: how can I flag this thread as solved?