2

All of our control panel URLs are being rewritten to show index.php?p=admin/***

While this isn't a problem in itself we can't determine why it's happening when the frontend of the website itself is writing the URLs cleanly and correctly without the index.php?p=

We have in our .htaccess file

<IfModule mod_rewrite.c>
  RewriteEngine On

  # Send would-be 404 requests to Craft
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_URI} !^/(favicon\.ico|apple-touch-icon.*\.png)$ [NC]
  RewriteRule (.+) index.php?p=$1 [QSA,L]
</IfModule>

There are no other Rewrites happening.

A possibly related issue we're seeing is that there are no entries, assets or categories listing in the control panel. Looking through the logs I can see the following

2015/09/22 16:55:23 [error] [exception.Craft\HttpException.400] exception 'Craft\HttpException' with message 'Param “elementType” doesn’t exist.' in /var/www/vhosts/mysite.org/httpdocs/craft/app/services/HttpRequestService.php:586
Stack trace:
#0 /var/www/vhosts/mysite.org/httpdocs/craft/app/controllers/BaseElementsController.php(50): Craft\HttpRequestService->getRequiredParam('elementType')
#1 /var/www/vhosts/mysite.org/httpdocs/craft/app/controllers/ElementIndexController.php(68): Craft\BaseElementsController->getElementType()
#2 /var/www/vhosts/mysite.org/httpdocs/craft/app/framework/web/CWebApplication.php(281): Craft\ElementIndexController->init()
#3 /var/www/vhosts/mysite.org/httpdocs/craft/app/etc/web/WebApp.php(784): CWebApplication->runController('elementIndex/ge...')
#4 /var/www/vhosts/mysite.org/httpdocs/craft/app/etc/web/WebApp.php(276): Craft\WebApp->_processActionRequest()
#5 /var/www/vhosts/mysite.org/httpdocs/craft/app/framework/base/CApplication.php(184): Craft\WebApp->processRequest()
#6 /var/www/vhosts/mysite.org/httpdocs/craft/app/index.php(62): CApplication->run()
#7 /var/www/vhosts/mysite.org/httpdocs/index.php(40): require_once('/var/www/vhosts...')
#8 {main}
REQUEST_URI=/index.php?p=admin/actions/elementIndex/getElements
HTTP_REFERER=http://mysite.org/index.php?p=admin/entries/pages
---
2015/09/22 16:55:23 [error] [application] Param “elementType” doesn’t exist.

******************************************************************************************************

We do have PATH_INFO installed and enabled on the server.

Craft Pro 2.4.2692

Any help would be much appreciated. Many thanks

Improve this question
6
  • Sounds like a dupe? Try this: craftcms.stackexchange.com/questions/4386/… – Brad Bell Sep 22 '15 at 19:40
  • Hi @BradBell I don't think it's the same problem. My .htaccess file is being used (if I put invalid apache config settings in there it breaks the whole site). Also I'm only seeing problems in the Control Panel, the sites front-end is working a treat! – Boxhead Sep 22 '15 at 19:51
  • You sure there's no parent .htaccess file above Craft's? The rules will inherit from each other. – Brad Bell Sep 22 '15 at 20:00
  • My bad, I was editing a staged version of the general.php config file. Adding 'omitScriptNameInUrls' => true fixed the URLs (must have cached false at some point). We're still experiencing trouble loading entries/assets/categories in the CP though. Any thoughts? – Boxhead Sep 22 '15 at 20:12
  • @BradBell Shall I re-ask the 2nd part to the question about not seeing entry/asset/category lists in the CP as a new question? – Boxhead Sep 22 '15 at 20:26
0

Have you tried adding 'omitScriptNameInUrls' => true, to your general.php settings?

http://buildwithcraft.com/docs/config-settings#omitScriptNameInUrls

Improve this answer
2
  • Hi @dgrebb, I've set that to true aswell as 'usePathInfo' => true but not seeing any change. – Boxhead Sep 22 '15 at 18:50
  • Hi @dgrebb, you were right about the omitScriptNameInUrls setting. That fixed the URLs but we're still seeing issues with no entry/asset/category lists loading in the CP. Any thoughts? – Boxhead Sep 22 '15 at 20:13
1

With regard to the 2nd part of the original question, whereby no entry, asset, category or user lists were display, this turned out to be a post_max_size issue in the php.ini config. It had been incorrectly set to 64MB rather than 64M.

Improve this answer
1
  • Interesting find. Glad you got it sorted! – dgrebb Sep 23 '15 at 14:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.