Coder Social home page Coder Social logo

webdevops / typo3-metaseo Goto Github PK

View Code? Open in Web Editor NEW
38.0 13.0 26.0 2.89 MB

TYPO3 MetaSEO Extension

Home Page: https://typo3.org/extensions/repository/view/metaseo

License: GNU General Public License v3.0

PHP 79.90% HTML 4.51% CSS 0.49% JavaScript 15.10%
typo3 typo3-extension seo meta-tags php typo3-cms

typo3-metaseo's Introduction

MetaSEO - Search Engine Optimization for TYPO3

stable v3.0.0 development v3.0.1 License GPL3

Average time to resolve an issue Percentage of issues still open

SensioLabsInsight

MetaSEO is an extension for TYPO3 CMS and provides an indexed google/xml-sitemap, enhanced metatag support and pagetitle manipulation. It's a replacement for the "metatag" extension and the successor of the discontinued extension "tq_seo".

Version status

MetaSEO is available via TYPO3's Extension Manager (TER) and via composer (TER, Packagist).

  • Development version 3.0.1-dev:

    • Branch master
    • TYPO3 Version: 8.7.x
    • composer via Packagist: composer require webdevops/metaseo:dev-master -o
    • Please be aware that the development version can break at any time
  • Stable version 3.0.0:

    • Branch v3.0
    • TYPO3 Version: 8.7.x
    • composer via TER: composer require typo3-ter/metaseo -o (recommended)
    • composer via Packagist: composer require webdevops/metaseo -o
  • Old-Stable Development version 2.1.1-dev:

    • Branch backport
    • TYPO3 Version: 6.2.x - 7.6.x
    • composer via Packagist: composer require webdevops/metaseo:dev-backport -o
    • Please be aware that the development version can break at any time
  • Old-Stable version 2.1.0:

    • Branch v2.1
    • TYPO3 Version: 6.2.x - 7.6.x
    • composer via TER: composer require typo3-ter/metaseo -o (recommended)
    • composer via Packagist: composer require webdevops/metaseo -o

For version specific information see changelog for MetaSEO

Found a bug? Have questions?

Please feel free to file an issue in our Bugtracker. To avoid feedback loops we suggest to provide

  • MetaSEO version
  • TYPO3 version
  • RealUrl version (if used)
  • PHP version
  • Web server and version (optional)
  • Operating system and version (optional)
  • Hoster name (in rare cases)

In case of issues, please update to the latest version of MetaSEO first. We also strongly recommend to use recent versions of TYPO3 CMS (6.2.28+, 7.6.12+) and RealUrl (2.1.5+)

MetaSEO users also meet on slack at #ext-metaseo.

Contribute

MetaSEO is driven by the community and we're pleased to add new contributions. If you want to provide improvements, please

  • make sure that an issue exists so that it is clear what your contribution is supposed to do. Eventually, open a new issue.
  • add a Fixes #123 to the message of your first commit, whereas #123 should be the issue number.
  • add yourself to the list of contributors when you send us your first pull request (PR).
  • provide as many commits in your PR as necessary. There's no single-commit policy, but one PR should not affect more than one issue (if possible).

The coding style of MetaSEO's source code follows the PSR-2 standard. Please enable PSR-2 support in your IDE or enable the editorconfig plugin. See .editorconfig for indentation.

typo3-metaseo's People

Contributors

c2po avatar danilovq avatar georg-tiefenbrunn avatar glucka avatar leitgab avatar m-arcus avatar mblaschke avatar mediaessenz avatar mmunz avatar pcvolkmer avatar pdanzinger avatar sicordev avatar simonschaufi avatar snduesel avatar stixits avatar thomaszbz avatar twaurisch avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

typo3-metaseo's Issues

Inherited page title prefix/suffix are not taken into account, if in a deeper page branch

Within the given conditions the suffix and the prefix of a page title is not taken into account.

Page tree

root (site title: My Company)
  |- Products (suffix: Our Products)
    |- Special Products (suffix: Automation products)
  |- bla

Title results

Products: Products Our Products: My Company
Special Products: Special Products Our Products: My Company

Conclusion

The suffix "Automation products" will never be used, because the higher level suffix is the first choice

Result

Make the prefix/suffix usage more configurable.

  1. use always the first x-fix in rootline (default)
  2. use always the last x-fix in rootline (IMHO the most expected behavior)
  3. allow chaining of the x-fix to create a breadcrumb-like page title (extensive)

Extension arbeitet nicht mit ext:robots (Robot tags)

Hallo,

ich würde gerne in meiner Seite für jede Seite alle möglichen Varianten der robots meta tags verwenden.
Allerdings bietet metaseo nur die Option "no-index,follow" für die Seiten an. Ich würde gerne für die redaktuere "no-index, no follow" oder "index, no-follow" verfügbar machen.

Ich hatte versucht die Extension "robots" neben "metaseo" zu verwenden, allerdings laufen die nicht miteinander. Bzw. werden die meta tags nicht ausgespielt.

Hat jemand eine Lösung für diese Frage?!

PHP Warnings

Core: Error handler (FE): PHP Warning: Invalid argument supplied for foreach() in /.../html/typo3/typo3conf/ext/metaseo/Classes/Utility/GeneralUtility.php line 178
Core: Error handler (FE): PHP Warning: array_reverse() expects parameter 1 to be array, null given in /.../html/typo3/typo3conf/ext/metaseo/Classes/Utility/GeneralUtility.php line 176
Core: Error handler (FE): PHP Warning: ksort() expects parameter 1 to be array, null given in /.../html/typo3/typo3conf/ext/metaseo/Classes/Utility/GeneralUtility.php line 173
Core: Error handler (FE): PHP Warning: Invalid argument supplied for foreach() in /.../html/typo3/typo3conf/ext/metaseo/Classes/Utility/GeneralUtility.php line 178

Double page title

The sitetitle and the glue is always output twice .

Example: Sitetitle | Sitetitle | Pagetitle

Apply PSR-2 coding style

PSR-2 is claimed for this project, but still not applied completely for existing code. I suggest to apply it before releasing the 2.0 version.

The reason for that is that for the moment there are not many forks of this project out there. Literally speaking, nearly all branches are clean. As soon as this changes, more and more code is changed in other branches leading to conflicts when merging them again after applying coding style. In the end, doing it now could avoid a lot of pain in the long run (aka the typo3 dilemma).

Plus, there's much lesser code to change in later 2.0 production versions leading to easier tracking of fixes. Currently, it's not easy for the reader to decide what is done for coding style and what is the actual fix/change.

remove menu separator from sitemap xml

Menu separator "pages" occur in the sitemap xml although there is no content for the entry.

How to reproduce:

  • website with existing menu, one entry per page
  • add new page of type "menu separator" (which is rendered as LI without a A href=... in the menu)

Result

  • There is a new entry for the menu separator page in the sitemap xml (which is wrong).
  • The corresponding request for the url returns 404 status code (which is correct!).

Suggested fix:

  • Remove menu separator items from sitemap xml or allow configuration (globally or per page)

Tested on pre-2.0.0 ( 598e3f6 )

Sitemap generated only for one page or not at all

Hi @mblaschke,
I'm testing the xml sitemap generation offered by your extension but it doesn't work.
I tested it in 2 TYPO3 installations.

In one case it outputs nothing:
http://pastebin.com/tkAHAN4w

In the second case it only outputs one page (the root page):
http://pastebin.com/TGuNgHQt
and it adds that parameter &page=1 that I guess it shouldn't be there to generate a realurl.

There's nothing special in these 2 installations.
Is sitemap working for you?

sitemap hat nur einen Record

habe eine Frage zu deiner Extension die ich in der aktuellen Version 1,0.8 auf Typo3 6.3 LTS einsetze und RealURL in v 1.12.8.
Die Seiten sind nicht auf "no cache" gesetzt und werden gecached.

Ich bekomme leider nur einen Record in meiner Sitemap (index.php?id=1&type=841132) ausgegeben. Und dieser Record scheint die Sitemap selbst zu sein:(

Im SEO > Control Center bei mir keine Domain… muss ich diesen Wert befüllen, bzw. eine domain record anlegen? Hatte das mal testweise gemacht allerdings hat dann mein realurl gestreikt und angefangen simulate static documents zu verwenden.
Unter „SEO > Sitemaps" hat er ca. 50 Einträge gefunden, und beide haken sind grün. Allerdings werden diese halt nicht in der sitemap ausgespielt.

W3C Validation: date, dc.date issues

w3c validation against HTML5 reports several errors
"Bad value date for attribute name on element meta: Keyword date is not registered."
"Bad value DC.date for attribute name on element meta: Keyword dc.date is not registered."

There is a Bunch of alternatives:
dc.created Date of creation of the resource.
dc.date.issued Date of publication for Google News. The format of the content is YYYY-MM-DD or YYYY-MM-DDThh:mm:ssTZD.
dc.modified Date on which the resource was changed.
dcterms.created Date of creation of the resource.
dcterms.date A point or period of time associated with an event in the lifecycle of the resource.
dcterms.issued Date of formal issuance (e.g., publication) of the resource. (DC doesn't spec a date format but the established practice is YYYY-MM-DD.)

Plus, there is:
dc.valid Date (often a range) of validity of a resource.
dc.dateSubmitted Date of submission of the resource.
dcterms.dateAccepted Date of acceptance of the resource.
dcterms.dateSubmitted Date of submission of the resource.

References:
http://validator.w3.org/
https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names
https://wiki.whatwg.org/wiki/MetaExtensions

Tested version is v1.0.5

regression in piwik javascript

There is a regression in TYPO3-metaseo/Resources/Private/Templates/PageParts/ServicePiwik.html
introduced by cd2b4fb.

Current develop version renders to

_paq.push(['setSiteId', 1]);
_paq.push(['setTrackerUrl', u + 'piwik.php']);
<
f:if condition = "" > _paq.push(['setDomains', '']);
</
f:if>
<
f:if condition = "" > _paq.push(['setCookieDomain', '']);
</
f:if>
<
f:if condition = "1" > _paq.push(['setDoNotTrack', '1']);
</
f:if>
<
f:if condition = "" > < f:
format.html
parseFuncTSPath = "" >  < /f:format.html></
f:if>

in the browser. For that reason, I now get a JavaScript error

Uncaught SyntaxError: Unexpected token <

in the Chromium browser. As a result, user tracking via piwik is broken and not willing to work at all.

Keep in mind, that this regression did not make it into a production version yet. This should be fixed before v2.0.0 is released.

I did not check other templates. Chances are high, that there's more affected templates.

Cache PageTitle

If PageTitle is set in extension (pibase or extbase) and there is another USER_INT/COA_INT object in TypoScript, the PageTitle is not set in cached version.

Solution: Make PageTitle cacheable

Docblock definition obsolete?

PSR2 seems not to complain if @Package, @subpackage and @Version are missing.

However, most of the classes contain a docblock with e.g.

 * @package     metaseo
 * @subpackage  lib
 * @version     $Id: ClassName.php 81677 2013-11-21 12:32:33Z someuser $

Either this needs to be required and documented or one could discuss if this is really needed in 2015:

  • We have git annotations for tracking of user, change date, version, commit message/history, ... per line, which is ways more precise.
  • And for the package information: Is that used somehow? We have PHP namespaces and we have composer and we have TYPO3 extensions which all three don't correspond to docblock package definition.
  • In a way, both of them are self-maintaining: Users can't commit without git and the application won't run correctly with wrong namespaces.
  • Plus, directory structure must correspond to namespaces

Personally, I don't like redundant information which needs to be maintained without any benefit (unless there is one!).

piwik: mixed content in <noscript>

On a https-secured page, a non-secured counter pixel is used in the tracking code for users that have no javascript-support:

<noscript><p><img src="http://example.com/piwik.php?idsite=1" style="border:0" alt="" /></p></noscript>

Piwik 2.12.0 uses

<noscript><p><img src="//example.com/piwik.php?idsite=1" style="border:0;" alt="" /></p></noscript>

which uses https on secured pages.

cleanup: search engine should get a complete and consistent sitemap ANY TIME.

How to reproduce:

  • After running garbage collection task, the sitmap is empty
  • After running sitemap.xml builder task, the sitmap is still empty
  • After clicking around on the page, the sitemap gets filled over the time. In the meantime, it is not consistent to the actual content of a web page.

Suggested enhancement:

  • There should be an automated way to clean up the sitemap leaving it in a filled state including ALL pages without clicking around manually.

Therefore

  • garbage collection task should execute the sitemap.xml builder task
  • sitemap.xml builder task should fill the sitemap with ALL pages

Result of the suggested enhancement: Cleanup and creation of sitemap.xml can be automated by running garbage collection and (optionally) sitemap.xml builder via TYPO3 scheduler.

Tested on pre-2.0.0 ( 598e3f6 )

page title doesn't appear

typo3 6.2.9, metaseo 1.0.6

i cannot set the page title over the extension. the constant "page title" is activated

Shortcuts generate "PHP Warning: ksort() expects parameter 1 to be array, null given in [...]"

Pages with a Shortcut generate the following PHP Warning in metaseo 1.0.5 and 1.0.6:

PHP Warning: ksort() expects parameter 1 to be array, null given in   [...]typo3conf/ext/metaseo/Classes/Utility/GeneralUtility.php line 173

We use the following TYPO3 configuration:

// Development
$GLOBALS['TYPO3_CONF_VARS']['BE']['debug'] = '1';
$GLOBALS['TYPO3_CONF_VARS']['FE']['debug'] = '1';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['devIPmask'] = '*';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['displayErrors'] = '1';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['enableDeprecationLog'] = 'file';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['sqlDebug'] = '1';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['systemLogLevel'] = '0';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['exceptionalErrors'] = '28674';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['clearCacheSystem'] = '1';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['debug'] = '1';

Sitemap only contains few pages

I used the scheduler task to generate the sitemap, but actually the sitemap (or rather the sitemap group) only contains 10 pages out of ~150 pages that should be indexed. Pages are cached correctly (table cf_cache_table is filled), so i don't think it's a caching-issue.

root-page is set, domain-records are set, followed instructions in your manual...
Did i miss something?

Version 1.0.8 (TYPO3 6.2)

By the way: With 'tq_seo' 6.0.1 it works like a charme...

W3C Validation: up link

w3c validation against HTML5 reports an error:
"Bad value up for attribute rel on element link: The string up is not a registered keyword."

This comes from "link rel="up" href=..."

Hint: start, next, priv, canonical are documented in the MetaExtensions Wiki and pass W3C validation. I suggest to add "up" to the wiki (if this is widely used) and comment it out in metaseo as long as the W3C validation fails.

References:
http://validator.w3.org/
https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names
https://wiki.whatwg.org/wiki/MetaExtensions

Tested version is v1.0.5

Refactoring: allow IDE magic for typo3 arrays

E. g. in class DatabaseUtility there is a bunch of expressions like

$GLOBALS['TYPO3_DB']->sql_...($res)

while IDEs typically cannot handle that. The benefit of changing that would be that you can navigate to the function in professional IDEs. Plus, you would see e.g. deprecated functions, code completition, parameters, ...

This would allow

/**
 * Free sql result
 *
 * @param resource $res SQL resource
 */
public static function free($res)
{
    if ($res && $res !== true) {
        self::getDb()->sql_free_result($res);
        //IDE is now showing me for parameter $res:
        //Expected bool|mysqli_result|object, got resource
    }
}

/**
 * @return \TYPO3\CMS\Core\Database\DatabaseConnection
 */
protected static function &getDb() //by reference
{
    return $GLOBALS['TYPO3_DB'];
}

Before applying this it must be tested that the DatabaseConnection object is really passed by reference.

Plus, you need to decide if you really want that or if there's other reasons to not accept this issue.

Plus, you need to decide if getDb() and similar helper functions should be in a separate class. The latter would centralize version specific backports if array entries change in typo3.

LBNL such larger refactorings require the merge of #38 first.

log: strpos() expects parameter 1 to be string

TYPO3 CMS log reports:

Core: Error handler (FE): PHP Warning: strpos() expects parameter 1 to be string, array given in /var/www/2bis10.de/wwwroot/typo3conf/ext/metaseo/Classes/Page/Part/MetatagPart.php line 559

for current develop version be871c7

This affects the following part of the code:

foreach ($keyList as $key) {
    if (!empty($tags[$key])) {
        foreach ($markerList as $marker => $value) {
            if (strpos($tags[$key], $marker)) {
                $tags[$key] = str_replace($marker, $value, $tags[$key]);
            }
        }
    }
}

The log entry occurs using TYPO3 CMS 6.2.11, PHP 5.6.7-1, Debian 8 (stable release)

W3C Validation: document-wide default language is obsolete

w3c validation against HTML5 reports an error
"Using the meta element to specify the document-wide default language is obsolete. Consider specifying the language on the root element instead."

This comes from the "meta http-equiv="content-language" content="de"", which can be safely removed, according to the w3c recommendation. Instead, the language can be set with "html lang="de"" which is already done.

References:
http://validator.w3.org/
https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names
https://wiki.whatwg.org/wiki/MetaExtensions

Improve detection of mounted pages

Currently mounted pages will generate a wrong canonical link, point it to the real page instead of the virtual page.

Mounting informations are available in rootline:
$GLOBALS['TSFE']->rootLine

schema.dc and schema.dcterms missing

https://wiki.whatwg.org/wiki/MetaExtensions suggests for most dc.* and dcterms.* meta extensions:

"It must be accompanied by a

<link rel="schema.dc" href="http://purl.org/dc/elements/1.1/">
<link rel="schema.dcterms" href="http://purl.org/dc/terms/">

element."

These links are missing in v1.0.5.

Hint 1: This issue is NOT reported as a warning/error by W3C validation.

Hint 2: I'm also not sure if this recommendation is valid for HTML4 and XHTML or if it breaks BC. For instance, I think it's fine.

W3C validation: schema.dc and schema.dcterms

schema.dc and schema.dcterms seem not to be registered in HTML5.

<link rel="schema.dcterms" href="http://purl.org/dc/terms/">

returns an error:

Bad value schema.DCTERMS for attribute rel on element link: The string schema.dcterms is not a registered keyword.

A proposed solution could be:

<html lang="de" itemscope itemtype="http://schema.org/LocalBusiness">
<head prefix="og: http://ogp.me/ns#; dcterms: http://purl.org/dc/terms">

with

<!-- Dublin Core -->
<meta property="dcterms:title" content="Website Title" />
<meta property="dcterms:description" content="Website Description" />
<!-- Open Graph -->
<meta property="og:title" content="Website Title" />
<meta property="og:description" content="Website Description" />
<!-- Schema.org -->
<meta itemprop="name" content="Website Title" />
<meta itemprop="description" content="Website Description" />

This avoids validation errors. However, I'm not sure if dublin core is evaluated that way by search engines etc. Plus,

<meta name="DCTERMS.title" content="...">

passes W3C validation without errors, because DCTERMS.* is registered by itself. So, the link could eventually be removed (although the link is required according to https://wiki.whatwg.org/wiki/MetaExtensions )

Suggestion:

  • Either use the proposed solution or comment out the existing link until this is registered and used in W3C validation.
  • Eventually, a specific behaviour for HTML5 is necessary (Compared to HTML4 or XHTML).

References:
http://www.aljtmedia.com/blog/resolving-html5-dublin-core-microdata-validation-issues/
https://wiki.whatwg.org/wiki/MetaExtensions

templates' syntax is broken

Similar to 1f55c3a, some other templates might be broken, e.g.

Resources/Private/Templates/PageParts/ServiceGoogleAnalytics.html

might be broken, too. It seems as if e.g. PhpStorm does not cope with the template syntax.

dc.subject: w3c validation error

w3c validation against HTML5 reports
"Bad value DC.Subject for attribute name on element meta: Keyword dc.subject is not registered. A metadata name listed in the HTML specification or listed in the WHATWG wiki. You can register metadata names on the WHATWG wiki yourself."

Hint: there is a "dcterms.subject" Meta extension. Maybe this one should be used instead.

References:
http://validator.w3.org/
https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names
https://wiki.whatwg.org/wiki/MetaExtensions

Core: Error handler (FE): PHP Warning

When I install metaseo at a "usually" working- typo3 installation, then I get the following prompts at the log. They appear about every 10-20 minutes.

bildschirmfoto 2015-04-22 um 08 32 20

Any idea how to handle the huge amount on rows at the log?
I can't clear the whole table, because I need the other logs for my customers and the memory is filled up with logs.

Clean standalone tags

Since the deprecation of config.xhtml_cleaning there is a problem with getting XHTML documents clean in Typo3. So it is necessary that the extensions produce clean code by itself.
This means that standalone tags should get closed correctly like

Till now I can clean it by config.xhtml_cleaning, but it is now just a feature of compatibility6

Refactoring: use functions in class MetatagPart

There's a bunch of statements of the kind

... = '<meta name="{name}" content="' . htmlspecialchars({content}) . '">';

and similar statements in class MetatagPart.

A function could be used for that leading to more maintainable code.
#38 needs to be merged before further refactorings make sense.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.